deprecate config using the One True ADS Server(tm)

Today, the way ADS is configured is as follows:

• The bootstrap file has an ads_config field indicating the One True ADS Server(tm).
• The bootstrap file has its lds_resource_locator and cds_resources_locator fields set to a ConfigSource with the ads field set.
• In resources sent from the management server, ConfigSource protos use the same ads field.

This approach seems incompatible with the new xDS naming scheme, which was designed to support federation. As part of the new naming scheme, the ApiConfigSource.ApiType enum now has AGGREGATED_GRPC and AGGREGATED_DELTA_GRPC values, which allows configuring any ConfigSource to use a single ADS stream instead of using a separate stream for each resource type. This way of configuring ADS seems much more in-line with the direction we're heading in and will make it easier to transition to the new federated world.

Therefore, I propose replacing this notion of the One True ADS Server(tm) with use of this new AGGREGATED_GRPC enum value. The typical ADS configuration described above would instead be represented as follows:

• The bootstrap file will not populate the ads_config field.
• The bootstrap file will have its lds_resource_locator and cds_resources_locator fields both set to the same server, with ApiType set to AGGREGATED_GRPC or AGGREGATED_DELTA_GRPC. (Envoy will internally de-dup these by hashing the ConfigSources, so the result will be a single ADS stream, not two separate ADS streams.)
• In resources sent from the management server, ConfigSource protos will use the self field.

This will require the following changes:

• Implement support for the self field. (This field was added in #8201 but is not currently implemented in Envoy.)
• Implement support for the AGGREGATED_GRPC and AGGREGATED_DELTA_GRPC values in the ApiType enum. (I'm not sure how much of this works right now.)
• Deprecate the bootstrap file's ads_config field.
• Deprecate the ads field.

The only configuration that would be broken by this change would be if someone was (e.g.) using non-aggregated LDS to get a Listener resource that contained a ConfigSource telling the client to get the RouteConfiguration via the One True ADS Server(tm). However, it seems exceedingly unlikely that anyone is actually doing that, and there are work-arounds: they can either have their management server send the exact ConfigSource containing the ADS server they want to talk to, or better yet, they can start using the new xDS naming scheme, where they can select the xDS server via an authority in the resource name itself.

CC @mattklein123 @htuch