API unification.

There are several kinds of APIs, the RPC, the http. From what I know, the rpc was created for the 'backward compatibility' with bitcoin core.

The outputs have different sets of fields presented, different names for the same fields, and even different naming conventions (camelCase vs lowcase).

For example, [here is the output of rpc `curl 127.0.0.1:12037/ -X POST -d '{ "method": "getblockbyheight", "params": [ 1, true, true ] }`](https://gist.github.com/randomlogin/41a8153645e14d6ca907a8cdcb82849b).

And [here is the output of `curl 127.0.0.1:12037/block/1`](https://gist.github.com/randomlogin/90f5574c43462a73ea69c9c1a6ef9d45).

The outputs use these functions:
RPC: https://github.com/handshake-org/hsd/blob/1a086e44b5b60e1ebb01955b0e1b2a0ebd00b42d/lib/node/rpc.js#L2819
HTTP: https://github.com/handshake-org/hsd/blob/1a086e44b5b60e1ebb01955b0e1b2a0ebd00b42d/lib/primitives/tx.js#L1726
and their analogues for the block presentation.

From what I think, the http api (which is stateless) is more useful and important and should contain full information.

So the questions/suggestions:
1. Is it really needed to have RPC api?
2. If rpc is still needed, change the 'main' api to the http and set rpc to use the same output as http.
3. Some kind of unification, say name the hash of the tx field as `txid`, etc.

Start by comparing lib/node/rpc.js at the referenced getblockbyheight handler with lib/primitives/tx.js and the analogous block presentation, using the linked RPC and HTTP outputs as examples. Before implementation, settle whether RPC remains supported and define the unified field names and response contract; done requires an agreed API design and matching output behavior.

Written by the indexing model from the issue text.