POC for /block

[andynog]

Closes: #1, #2, #3 and #4

This is the initial logic to insert a block into the database then expose an endpoint /block via the RPC Companion service to serve a response that matches a block response from the full node

[andynog]

This POC implementation relies on the data to be normalized and stored in the database. This seemed to be a good approach initially that would provide lots of benefit in the future for indexing data or creating additional endpoints that would return the data in different shapes and formats that could cater to different use cases.

But as the work progressed, it became apparent that the effort to normalize the data was very time consuming and was not progressing as fast as expected. There are data structures that encompass various levels of nested structures such as the light client attack evidence.

Adding a database schema that could persist this normalized data was very tricky and doesn't seem the way to go. Will merge this code since the logic to return a /block works and it was almost 95% implemented. The work also done in this branch to separate the logic into services is a good start and independent of the underline logic database, which means it can still be re-used after a refactoring.

The next step would be to pivot the POC to focus on an integration test approach. For example select a use case, like a relayer client and create a POC that works with that. The data can be persisted in simpler ways (e.g. minimal structured data and blog storage for nested structure). This should make this solution more feasible and development easier. This will be tracked on a different PR/issue.