GET - `/eth/v1/validator/{pubkey}/feerecipient` - Specify expected behaviour when the fee recipient is not registered for `{pubkey}`

## Issue description:

When calling `/eth/v1/validator/{pubkey}/feerecipient` for a `{pubkey}` with **no** fee recipient registered, the response differs depending of validator client implementation:

**Lighthouse:**
Lighthouse response is
```
{
"code": 500,
"message": "INTERNAL_SERVER_ERROR: no fee recipient set",
"stacktraces": []
}
```
(Note: https://github.com/sigp/lighthouse/issues/3507 is open about error code)

**Teku:**
Teku does not allow to start a validator client without setting a fee recipient.
At start, Teku validator client logs are:
```
2023-01-30 12:53:28.336 FATAL - Invalid configuration. --validators-proposer-default-fee-recipient or --validators-proposer-config must be specified when Bellatrix milestone is active
```
then Teku validator client quits.

==> A user cannot query `/eth/v1/validator/{pubkey}/feerecipient` on a Teku validator client if no (at least default) fee recipient is registered for `{pubkey}`.

**Prysm:**
Currently, Prysm validator client uses a custom [gRPC API](https://docs.prylabs.network/docs/how-prysm-works/prysm-public-api) to communicate with the beacon node.

This gRPC API has special `GetFeeRecipientByPubKey` method which is the `GET` equivalent of Beacon API [prepareBeaconProposer](https://ethereum.github.io/beacon-APIs/#/Validator/prepareBeaconProposer): The request body contains a validator pubkey. The beacon node responds the corresponding fee recipient. If no specific fee recipient for this pubkey is known by the beacon node, then the beacon node answers the default fee recipient specified in beacon node configuration. If **no** default fee recipient is specified in beacon node configuration, then the beacon node answers the burn address `0x0000...`.

## Proposals:
### Proposal 1:
Define in **Key Manager API** specification that any call to `/eth/v1/validator/{pubkey}/feerecipient` validator client API with `{pubkey}` with no registered fee recipient should return `HTTP 404`.

### Proposal 2:
Define in **Beacon API** specification a new `GET` `fee_recipient` method. This method could take in query parameters a list of validators pubkey/index and could return corresponding fee recipient addresses.
In this case, the call to `/eth/v1/validator/{pubkey}/feerecipient` **validator client** API will be able to answer the default fee recipient specified in **beacon node** configuration if no specific fee recipient is registered for `{pubkey}` in the validator client.

However, if `{pubkey}` has a registerd fee recipient in the validator client configuration, the validator client will have 2 possibilities:
1. Returning directly fee recipient **from validator client configuration** corresponding to `{pubkey}`
2. Querying the newly defined **Beacon API** `GET` `fee_recipient` method and returning the result.

`1.` and `2.` may differ.