Implement VC API (#1657)

## Issue Addressed

NA

## Proposed Changes

- Implements a HTTP API for the validator client.
- Creates EIP-2335 keystores with an empty `description` field, instead of a missing `description` field. Adds option to set name.
- Be more graceful with setups without any validators (yet)
    - Remove an error log when there are no validators.
    - Create the `validator` dir if it doesn't exist.
- Allow building a `ValidatorDir` without a withdrawal keystore (required for the API method where we only post a voting keystore).
- Add optional `description` field to `validator_definitions.yml`

## TODO

- [x] Signature header, as per https://github.com/sigp/lighthouse/issues/1269#issuecomment-649879855
- [x] Return validator descriptions
- [x] Return deposit data
- [x] Respect the mnemonic offset
- [x] Check that mnemonic can derive returned keys
- [x] Be strict about non-localhost
- [x] Allow graceful start without any validators (+ create validator dir)
- [x] Docs final pass
- [x] Swap to EIP-2335 description field. 
- [x] Fix Zerioze TODO in VC api types.
- [x] Zeroize secp256k1 key

## Endpoints

- [x] `GET /lighthouse/version`
- [x] `GET /lighthouse/health`
- [x] `GET /lighthouse/validators` 
- [x] `POST /lighthouse/validators/hd`
- [x] `POST /lighthouse/validators/keystore`
- [x] `PATCH /lighthouse/validators/:validator_pubkey`
- [ ] ~~`POST /lighthouse/validators/:validator_pubkey/exit/:epoch`~~ Future works


## Additional Info

TBC

book/src/api-vc-auth-header.md

@@ -0,0 +1,55 @@
+# Validator Client API: Authorization Header
+
+## Overview
+
+The validator client HTTP server requires that all requests have the following
+HTTP header:
+
+- Name: `Authorization`
+- Value: `Basic <api-token>`
+
+Where `<api-token>` is a string that can be obtained from the validator client
+host. Here is an example `Authorization` header:
+
+```
+Authorization Basic api-token-0x03eace4c98e8f77477bb99efb74f9af10d800bd3318f92c33b719a4644254d4123
+```
+
+## Obtaining the API token
+
+The API token can be obtained via two methods:
+
+### Method 1: Reading from a file
+
+The API token is stored as a file in the `validators` directory. For most users
+this is `~/.lighthouse/{testnet}/validators/api-token.txt`. Here's an
+example using the `cat` command to print the token to the terminal, but any
+text editor will suffice:
+
+```
+$ cat api-token.txt
+api-token-0x03eace4c98e8f77477bb99efb74f9af10d800bd3318f92c33b719a4644254d4123
+```
+
+### Method 2: Reading from logs
+
+When starting the validator client it will output a log message containing an
+`api-token` field:
+
+```
+Sep 28 19:17:52.615 INFO HTTP API started                        api_token: api-token-0x03eace4c98e8f77477bb99efb74f9af10d800bd3318f92c33b719a4644254d4123, listen_address: 127.0.0.1:5062
+```
+
+## Example
+
+Here is an example `curl` command using the API token in the `Authorization` header:
+
+```bash
+curl localhost:5062/lighthouse/version -H "Authorization: Basic api-token-0x03eace4c98e8f77477bb99efb74f9af10d800bd3318f92c33b719a4644254d4123"
+```
+
+The server should respond with its version:
+
+```json
+{"data":{"version":"Lighthouse/v0.2.11-fc0654fbe+/x86_64-linux"}}
+```