internal/ethapi: add eth_nextNonce RPC method

[yondonfu]

#15794 notes that any client relying on Geth for the next nonce by using the eth_getTransactionCount RPC method will run into the issue of duplicate nonces if the client attempts to submit concurrent transactions. Changing eth_getTransactionCount(.., "pending") to ask the local node's transaction pool would be backwards incompatible because it would break the current definition of pending state (the pending block if you are a miner or the latest canonical block if you are not a miner).

This PR is a basic first attempt to mimic Parity's custom parity_nextNonce RPC method (https://github.com/paritytech/parity/wiki/JSONRPC-parity-module#parity_nextnonce) with a new eth_nextNonce RPC method. An additional benefit to adding this RPC method might be eventual cross compatibility.

PendingNonceAt is usually used to retrieve the pending nonce for an account - perhaps an additional NextNonceAt can be defined as well which uses the eth_nextNonce RPC method to also preserve the current definition for PendingNonceAt.

[holiman]

I'm afraid that nextNonce will "kind of" work, but not really. Because there will be a gap between getting the nonce and submitting it. Any nextNonce requests submitted in that gap will get the same nonce again.

So while the situation will improve, it'll lead to more bug reports. For concurrent submission and nonce-issuance, we can get much better guarantees about concurrency when being in charge of both setting the nonce and submitting the transaction at the same time (as it does in sendTransaction).

I'm not in favour of adding an RPC-method which people think will solve a problem, but only solves it partially.