harmonize `setupServerAPI` with required engine API `eth` namespace methods
https://github.com/status-im/nimbus-eth1/pull/2654 switched the default RPC methods from `setupEthRpc` to `setupServerAPI`. This fixed many things, but also, the two RPC methods exposed don't entirely overlap, and, e.g., `eth_sendRawTransaction` isn't part of `setupServerAPI` but it is part of `setupEthRpc`. The same is true for several other required engine API RPC methods in the `eth` namespace.

In particular, the engine API requires the `engine_foo` methods [but also](https://github.com/ethereum/execution-apis/blob/v1.0.0-beta.4/src/engine/common.md#underlying-protocol):
> To facilitate an Engine API consumer to access state and logs (e.g. proof-of-stake deposits) through the same connection,
the client **MUST** also expose the following subset of `eth` methods:
> * `eth_blockNumber`
> * `eth_call`
> * `eth_chainId`
> * `eth_getCode`
> * `eth_getBlockByHash`
> * `eth_getBlockByNumber`
> * `eth_getLogs`
> * `eth_sendRawTransaction`
> * `eth_syncing`

Typically, an EL might expose these `eth_` methods both in a non-JWT-protected JSON-RPC way for non-engine consumers. So there are three classes of JSON-RPC endpoints:
- not required by the engine API, so can exist only in the non-JWT/non-engine API set of endpoints; it's ok to simply not have those for engine API at all;
- required by both engine API and non-engine API (the above list, `eth_blockNumber`, `eth_call`, `eth_chainId`, et cetera); these have to be available under both engine API and non-engine API access mechanisms (functionally, JWT and non-JWT, primarily, even if they share a port and JSON-RPC protocol); and
- required only by engine API, basically the `engine_` namespace, which cannot exist outside JWT protection by spec.