New admin endpoint /tap/config_ids

**Title:** New admin endpoint `/tap/config_ids`

**Description:**

Currently, the `/tap` admin endpoint makes it easy to start trace captures on Envoy instances that you are familiar with the configuration for. However, as an Envoy operator unfamiliar with reading the Envoy `/config_dump` output, determining the valid config_id strings that can be used in a `/tap` request can be difficult. This is currently a sticking point at Uber, and I imagine is a common sticking point when getting started with the `/tap` endpoint.

Currently, the best way I have found for generating a list of config_ids is to hit the `/config_dump` endpoint and pipe the output into `grep` searching for the string "config_id". Unfortunately, this often results in long lists of seemingly duplicate config_ids, which is still unclear for an envoy operator unfamiliar with the Envoy configuration. One approach we could take to solve this issue is to flesh out the command pipeline above to parse the `/config_dump` output. While this would work, I imagine it would introduce some unneeded complexity and that this functionality could be better implemented elsewhere.

This change proposes an alternate solution to the problem of obtaining config_id strings by introducing a new admin endpoint at `/tap/config_ids` that would dump a newline-separated list of valid "config_id" strings for the given Envoy host.

**Implementation:**

Our proposed Implementation for this feature is to pull the `config_id_map` stored in the `AdminHandler` into its own singleton class and make it accessible to the `AdminHandler` and a new `ConfigIdsHandler` class. The `ConfigIdsHandler` class will have a handler method registered as an admin handler in the same way as other admin handlers like `/config_dump`.

Uber currently has the resources to take on the development of this feature, and we would appreciate feedback on our proposal!