Improvements to the new RPC.

[kayabaNerve]

The new RPC (#279) is having planned features removed in order for it to continue in a timely fashion.

The most notable is the lack of HTTP pipelining. That said, we also have a lack of spec compliance thanks to a lack of GET/HEAD support (just returning a 404). We arguably shouldn't bother with the 404, yet I do want it noted.

Finally, there's a lack of testing, mainly due to the implicitness/irrelevance of a lot of this stuff.

Untested HTTP errors:

• 400
• 405
• 411
• 413
• 415
• 417
• 431
• 505

Un-explicitly tested RPC routes:

• quit
• getStatus
• getPublicKey
• getNickname
• getMerit
• getHeight
• getDifficulty
• getTotalMerit
• getUnlockedMerit
• publishBlock (though this is arguably tested explicitly enough, as is most of the above; this one is thanks to being complimentary to getBlockTemplate, which is explicitly tested)
• getPeers

I also want to add in a RPC method, merit_getSupply, to get the current Meros supply. It'd be defined as:

### `getSupply`

`getSupply` replies with the total amount of minted Meros in existence. The result is an int of the current supply.

Notable similarities with #272.

[kayabaNerve]

Some of these, generally the RPC routes, do need to be tested before launching.

[kayabaNerve]

Another casualty is the multi-account support of the personal RPC (not the multi-address support; referring to BIP 44). It's not needed and greatly simplifies the APIs. In the future, they can be added via optional fields.

Also removing hardened address generation.

[kayabaNerve]

personal_getTransactionHistory will be needed for the Wallet GUI.

personal_getBalance to compliment transactions_getBalance as personal_getUTXOs compliments transactions_getUTXOs would be great.

[kayabaNerve]

The above commit adds a task of expanding the WalletDB test as well.

[kayabaNerve]

Some of the following should've been done as part of the main PR. That said, it's dragged on too long, and I really just want to merge it. None of these need to be done, from a technical perspective, and they do generally fall under our extremely comprehensive commentary about testing.

• Restricting access to .token on the filesystem level would be beneficial. This is a feature that's completely legitimate to move here.

• The HTTP code's ability to respond with an optimal content type definition isn't tested.

• network_connect isn't tested.

• TGUCompetingSend, a test defined as

  Send + Verify - present
  Spend - Not present
  Competitor, that doesn't spend Send, verifies, beating Spend - Not present, as neither should verify yet due to Meros only verifying through finalization due to competition
  Competitor finalizes - present

  wasn't written.

The last one is actually somewhat important; Meros won't handle this edge case. A UTXO mutated in such a way won't become present on step 4 under the current codebase.

[kayabaNerve]

merit_getSyncProgress would also be a useful RPC route, notably for the GUI, When syncing to the point we need a block list, we can set known chain length to the result of the list BEFORE verifying the headers, yet also noting the chain as "untrusted" until AFTER we verify them. Current progress is defined as how many block bodies we've processed.

[kayabaNerve]

Should likely be network_getSyncProgress.

[kayabaNerve]

The above getTransactionHistory is untested; the Personal Send test would be great to shim its test into.