[Bug] macOS framework issues

Nobody has claimed this yet.

### Brief Issue Summary

This is related to: https://github.com/microsoft/vscode-cpptools/issues/13993
I assumed this was an issue in cpptools, but it might be an issue with CMake Tools.

In a simple example that explicitly specifies a “framework search path” using a `-F` (or `-iframework`) arg to `target_compile_options`, everything seems to work fine. i.e.

```
cmake_minimum_required(VERSION 3.16)
project(HelloFrameworkApp LANGUAGES CXX)
set(CMAKE_CXX_STANDARD 17)
add_executable(hello main.cpp)
target_compile_options(hello PRIVATE "-F/path/to/MyFrameworksRoot")
```

In that case, I can see the `-F` (or `-iframework`) simply being passed through to cpptools as a compiler arg and handled correctly. Note that these are "framework search paths" (a root containing other directories with `.framework` extensions), and not individual frameworks (just the name of the framework, such as passed to the `-framework` linker arg) or framework header paths (i.e. `/path/to/MyFramework.framework/Headers`). The later two are not needed by cpptools, as include paths or otherwise. For macOS frameworks, we need only the "framework search path" variety (`-F`, `-iframework` or `iframeworkwithsysroot`, not `-framework`).

However, with a simple Qt example:

```
cmake_minimum_required(VERSION 3.16)
project(HelloQt LANGUAGES CXX)
set(Qt6_DIR "/Users/colen/Qt/6.9.3/macos/lib/cmake/Qt6")
find_package(Qt6 REQUIRED COMPONENTS Widgets)
add_executable(HelloQt main.cpp)
target_link_libraries(HelloQt PRIVATE Qt6::Widgets)
set_target_properties(HelloQt PROPERTIES
MACOSX_BUNDLE TRUE
MACOSX_BUNDLE_GUI_IDENTIFIER com.example.helloqt
MACOSX_BUNDLE_BUNDLE_NAME "HelloQt"
)
```

... we're not getting that arg passed through for some reason, despite it being present (`-iframework`) on the build command line. In this case, I see the path appear in the set of include paths. I'm guessing that is due to the following code:

```
const frameworkPaths = Array.from(new Set((fileGroup.frameworks ?? []).map(f => path.dirname(f.path))));
const includePath = (fileGroup.includePath ? fileGroup.includePath.map(p => p.path) : target.includePath || []).concat(frameworkPaths);
```

Is there a reason the behavior differs between these scenarios? Passing through as argument would be preferred as it's less ambiguous.

If this is a work-around due to frameworks potentially being handled by CMake in multiple ways, it might be preferrable to compose new `-F` or `-iframework` (if isSystem is true) args out of them, than to make the contents of the include paths array ambiguous. (Only clang and gcc support macOS frameworks, so the args should be reliable)

### CMake Tools Diagnostics

```shell
n/a
```

### Debug Log

```shell
n/a
```

### Additional Information

_No response_

Start by tracing how the CMake target_compile_options case and the Qt6::Widgets case populate fileGroup.frameworks, includePath, and compiler arguments. Compare the shown frameworkPaths/includePath handling with the generated build command line, using the two minimal CMake examples as reproductions. Done means macOS framework search paths are represented consistently and the behavior is covered by an appropriate test or verified reproduction.

Written by the indexing model from the issue text.