[CMAKE] Add support for CMake component deprecation and update the policy

[dbarker]

Fixes # (issue)

The project provides CMake components in the installed package for use with find_package(opentelemetry-cpp COMPONENTS ...). The names of the components and targets they import are user facing and need a path for deprecation as things change.

Some use cases for this include:

• merging components:
  The config builder components can be merged with the exporter components they depend on since they bring in no new dependencies.
• moving components to opentelemetry-cpp-contrib.

This PR adds support to the otel_install_component CMake function for renaming and merging components while deprecating old component names. Users who call find_package on a deprecated component name will see a deprecation warning while the old component name resolves to the new component name.

This change is a part of #4240 and tested in that PR.

Changes

• update CMake install scripts in ./cmake/
  • Add DEPRECATED_NAMES and DEPRECATED fields to the otel_install_component function
• update the installed CMake template files to support resolving deprecated component names to the new component names.
• update the deprecation policy to include CMake components.

For significant contributions please make sure you have completed the following items:

• CHANGELOG.md updated for non-trivial changes
• Unit tests have been added
• Changes in public API reviewed

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 81.24%. Comparing base (cf62199) to head (1b861d9).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4272      +/-   ##
==========================================
- Coverage   81.25%   81.24%   -0.01%     
==========================================
  Files         446      446              
  Lines       18872    18872              
==========================================
- Hits        15332    15330       -2     
- Misses       3540     3542       +2     

see 1 file with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[lalitb]

Thanks @dbarker. This makes sense for #4240 and lets us merge the builder components without breaking existing users. Just wondering if we should keep this PR focused on on DEPRECATED_NAMES, add a small test here, and leave the unfinished DEPRECATED support for later when we have a real use case.

[dbarker]

Thanks @dbarker. This makes sense for #4240 and lets us merge the builder components without breaking existing users. Just wondering if we should keep this PR focused on on DEPRECATED_NAMES, add a small test here, and leave the unfinished DEPRECATED support for later when we have a real use case.

Thanks @lalitb. I've addressed the feedback. To add the small test I've moved the existing install "usage tests" into an install_functions_test folder and created new ci script targets for cmake.install_functions.test. This test injects a mock deprecated component into the build and verifies it is resolved correctly through find_package. I've also added setting the deprecated components _FOUND flag. Let me know if you spot anything else.

[ThomsonTan]

The alias resolver is single-pass over the original request list: foreach(_COMPONENT IN LISTS ${requested_components_inout}) iterates the input, and the replacement is only list(APPEND)-ed to _result, so a replacement that is itself deprecated is never resolved further. That makes this a one-hop lookup rather than a resolve-to-final.

[ThomsonTan]

if() re-dereferences an unquoted left operand that names a defined variable, so if(${_COMPONENT} IN_LIST ...) can take the wrong branch.

[ThomsonTan]

Unused variable?