cmStandardLevelResolver: Use flag if extensions don't match compiler's default, don't add flag if not necessary

• Renamed language_dialect to language_standard to better reflect its meaning.
• Add detection of whether compiler extensions are enabled by default or not.
• Fix compiler extensions not being turned off when no standard level was requested.
• Avoid adding standard level flags if not necessary (i.e. matches the compiler's defaults).

TODO:

• Add a policy for "Standard flags are no longer added if mode matches desired". This breaks existing code when:

  • LANGFLAGS=<flag for standard newer than CMAKE_LANG_STANDARD_DEFAULT>
  • LANG_STANDARD<CMAKE_LANG_STANDARD_DEFAULT
  • LANG_EXTENSIONS=CMAKE_LANG_EXTENSIONS_DEFAULT=ON
  • LANG_STANDARD_REQUIRED=OFF
  • Project relies on LANG_STANDARD being the standard.

  Previously we'd always add the flag if LANG_EXTENSIONS=ON, but we no longer do. In such cases the project should set LANG_STANDARD_REQUIRED=ON to make sure it gets the exact mode it specified.

• Add tests for LANG_STANDARD_REQUIRED=ON really passing the flag. Need to select a combination which the compiler's default mode doesn't match. Should help catch this mistake.

  Resolution: This is mostly already covered, the referenced typo would be caught by the tests for the next case.

• Add tests for LANG_STANDARD is unset and LANG_EXTENSIONS!=CMAKE_LANG_EXTENSIONS_DEFAULT that the correct flag is passed. I.e. a test case for #22224 (closed).

• Figure out why BootstrapTest is failing on Solaris. For some reason std::unique_ptr isn't available without any flags. Incorrect default standard detection?

  Resolution: Removed incorrect check for ext != defaultExt. It wasn't actually necessary and would result in us trying to use non-existant flags in cases where LANG_STANDARD!=CMAKE_LANG_STANDARD_DEFAULT and LANG_EXTENSIONS!=CMAKE_LANG_EXTENSIONS_DEFAULT.

• Figure out CrayPE GTK2 failures. Expecting a brace likely due to the __attribute__((__deprecated__("whatever"))). Needs GNU mode, default wrongly detected?

  Resolution: Magically went away, might've been caused by something else.

• Add references/updates to the policy to the relevant generic language/extension pages.

  • cmake-compile-features(7)'s "Availability of Compiler Extensions"
  • <LANG>_STANDARD, <LANG>_EXTENSIONS

• Add warnings for the policy.

• Add tests for the warnings. Requires introspection.

• Update release notes to refer to the policy.

• Figure out the reasons for nightly failures with the policy set to NEW.

Improved introspection from generate_feature_list in this MR should help with adding the additional tests depending on the environment.