SSZ Support for `submitBlindedBlock ` and `getHeader` endpoints

With https://github.com/ethereum/builder-specs/pull/104 accepted to the spec, we should update with the required changes.

Note that I'm not overly familiar with the relay codebase, so take all of the below with a grain of salt, but this is my proposed set of changes:

Overall Goal
=========

So to reiterate the above builder-spec PR, the goal is to support SSZ for these endpoints in a backwards compatible way:

- before SSZ support lands, the relay should return appropriate 4xx error codes
- `getHeader ` should allow SSZ encoding of the response.
- `submitBlindedBlock` should allow both SSZ requests and responses.

## Milestone 0: Housekeeping (GetPayload vs SubmitBlindedBlock)

When researching the required changes, one thing that threw me off is that the builder-spec refers to the `/eth/v1/builder/blinded_blocks` endpoint as the `submitBlindedBlock` operation here: https://github.com/ethereum/builder-specs/blob/main/apis/builder/blinded_blocks.yaml#L2

However the mev-boost-relay codebase uses the term `getPayload` for that operation. IMO we should consider updating the code to use `submitBlindedBlock` instead. However, the term "Get Payload" is used in DB schemas and metrics, so this might not be practical.

## Milestone 1: Explicitly reject SSZ

### Accept header parsing

So, the first step is IMO to parse the suggested `Accept` header, and explicitly reject any that resolve to anything other than `application/json`.

The logic should largely involve:

- Update `handleGetHeader` and `handleGetPayload` (or `handleSubmitBlindedBlock` if milestone 0 occurs) to parse the `Accept` header.
- Be sure to handle the weighted case as outlined at https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept
- If the `Accept` header does not contain `application/json` (at any weight) then return status 406 as outlined here: https://github.com/ethereum/builder-specs/blob/main/types/http.yaml#L24

### Content-Type parsing

Next, the `handleGetPayload`/`handleSubmitBlindedBlock` handler should correctly reject SSZ (or any non-JSON `Content-Type`):

- If Content-Type is omitted, assume JSON.
- If Content-Type is included but contains any value other than `application/json` the endpoint should return a 415 as outlined here: https://github.com/ethereum/builder-specs/blob/main/types/http.yaml#L47

The above is the minimal change required to be "in spec" with the SSZ updates, but of course we should continue on to actually supporting SSZ.

## Milestone 2: SSZ Support

With Milestone 1 in place, we can go forward with actually supporting SSZ, which would entail:

In `handleGetPayload`:

- Allowing `application/octet-stream` in the `Content-Type` header.
- Requiring the `Eth-Consensus-Version` header if `Content-Type: application/octet-stream` is included.
- Decode the payload as either SSZ or JSON based on the `Content-Type` header.

And in both `handleGetHeader` and `handleGetPayload`:

- Allow `application/octet-stream` in the `Accept` header.
- Add a new `RespondWithContentType` or similarly named method that can respond w/ both JSON and SSZ, use this instead of `RespondOK` (`RespondError` and continue to only send JSON).

Also note that Milestone 2 *must* be deployed _atomically_ since allowing `Accept: octet-stream` in the `handleGetPayload` handlers is how relays signal that they support SSZ for both endpoints.