Add a little logic to CORS config processing and significantly update the CORS doc

[tjquinno]

Description

Resolves #8026

The change in 4.x in how built-in features such as metrics and health are automatically discovered and activated did not revise the CORS doc so the descriptions particularly for how to control the CORS behavior for those features had fallen out of step with how Helidon behaves.

Also, because these services no longer require explicit developer code to add them to an SE web server, we needed to allow CORS to rely on configuration to establish the settings for those services.

This PR contains two important changes:

1. It adds logic to the CORS Aggregator to allow the user to set up CORS behavior for any endpoint--including the built-in services--using only configuration.

   (The role of the Aggregator in CORS has always been to pull together the CORS set-up from multiple places: explicitly coded CorsSupport instances, config, and MP annotations.)

2. It significantly updates the CORS-related doc:

   1. The doc now emphasizes the config-only approach and recommend it. This is much simpler, and it is functionally equivalent to the previous way in which developers created one or more CorsSupport instances and included it them in the routing for their services or endpoints.
   2. The doc now (correctly) describes how to control CORS for the built-in services--using config.

Documentation

The PR includes doc updates.

[tomas-langer]

I cannot really review the docs language, for the rest I am OK