Add RequestID to http handler and store as a context value

#### Feature Description

RequestIDs are a common industry pattern for uniquely identifying a request throughout its lifecycle. In HTTP systems, typically they are generated by the server accepting the initial request and propagated via the header `X-Request-ID`. I'll call this behavior generate-or-propagate, where you take an ID if it's given or make a new one.

Once we've generated or accepted an X-Request-ID, we can store it as a value on the `req.Context` to be passed through to whatever endpoint are handles the request.

It's OK for these requestIDs to end at the RPC layer for a first iteration. Down the line we can see about adding generate-or-propagate behavior to RPCs and adding RequestIDs to our RPC structs.

#### Use Case(s)

This is primarily a debugging-focused feature. RequestIDs give us a mechanism to uniquely identify a request in logged events and more deeply inspect Consul's behavior. The main use case is correlating Consul's logs to a specific HTTP response. Also, if users have instrumentation set up to propagate their own requestIDs, then Consul can participate.

Down the line, when we implement RPC-level propagation, we'd be able to view a set of logs across various multiple Consul processes by selecting the RequestID. The ID can also compose with other debugging features - if we were to store the RequestID in tracing spans we'd be able to correlate a set of traces with the logs of the request(s) involved.

#### Out of scope
When this issue is completed, we should create an issue for generating-or-propagating RequestIDs through our RPC layer.