Muting an extremely chatty log line.

Fixed endpoint tests.  Also more boolification.

Changed teeny weeny font for protobuf landing page snippet

There are multiple uses for opaque metadata that is associated with the
specific listener/filter chain/route that a request matches on:

1. Logging. Similar to header values, we can log the metadata values.
   A listener might belong to a higher level concept in the
   configuration language that generated LDS protos, e.g. there might be
   a rule identifier expressed. This metadata allows logs to reflect the
   rule identifier.

2. Future custom stats backends might use metadata to guide where and
   how stats are emitted. E.g. the metadata might include information
   about which stats collector to emit to.

3. Proprietary filters can receive additional inputs via the metadata.
   The per-filter metadata generalizes and replaces the opaque_config in
   RDS ForwardAction.

The metadata is structured such that each filter's metadata is under the
reverse DNS namespace defined by the filter. Shared metadata may be
arranged by coordinating on the reverse DNS namespace.

As an example, the "envoy.http_connection_manager.access_log" filter
namespace is suggested to be used for HTTP access logging.

Fixes #33.