Enhance IBC query methods usability and code organization

[Farhad-Shabani]

Background

Not all hosts may supply needed endpoints for relayers through tonic's gRPC services, but our query methods’ implementation for IBC core client, connection, and channel can still be utilized by different query service providers.

Furthermore, hosts may wish to expose specific IBC query methods, not all in the first place. Particularly some chains may not initially include the upgrade_client capability and, consequently, can’t construct ClientQueryService. However, they still require the ability to expose certain RPC endpoints, especially for testing purposes during their development phase.

These considerations became particularly relevant when attempting to implement IBC query endpoints for Sovereign SDK chains. (this issue). In this context, jsonrpsee dependency was used, and the registration of RPC methods was intertwined with existing RPC methods, preventing us from leveraging our gRPC implementation as is.

Proposal

To enhance the usability of the grpc feature, we should make all method implementations available as standalone functions, and accessible to the public.

Furthermore, given our broader vision of maintaining various parts of ibc-rs implementation (e.g., core, apps, clients, mocks, etc.) in individual crates, it would be beneficial to separate the relevant query codebase into a distinct crate. This approach simplifies management and allows for the inclusion of comprehensive tests for these endpoints in the future.

Worth noting that with these proposed changes, we won't solely serve the gRPC services. Instead, we can cater to a wider range of use cases, thus, the new crate can be named something like: ibc-query