FetchContent can lead to inconsistent directory properties

Consider the case where we have:

FetchContent_Declare(
  A
  ...
  OVERRIDE_FIND_PACKAGE
)

FetchContent_Declare(
  B
  ...
  OVERRIDE_FIND_PACKAGE
)

FetchContent_MakeAvailable(A B)

and additionally, library A depends on library B, and the CMakeLists.txt for library A calls find_package(B).

Due to the way FetchContent is implemented, this leads to library B being added as a subdirectory of library A, which means it inherits the directory properties from library A, which is likely to be unexpected and undesirable.

There are several possible workarounds:

• Inject (e.g. via a patch) code into library A and library B to try to reset important directory-level properties. Unfortunately for the DEFINITIONS property this is impossible due to #24010.

• If the dependency graph is known, we can specify the packages to FetchContent_MakeAvailable in topologically-sorted order. But in some cases the dependency graph is not readily available, since it may not otherwise be required.

I think the ideal solution would be to allow a PARENT argument to add_subdirectory that specifies that some other directory (already known to CMake) will serve as the parent, rather than the current directory. Then FetchContent could use this option to support more consistent property inheritance when using FetchContent.