Put brotli on the FetchContent plan

[jkoritzinsky]

Consume our brotli dependency through FetchContent like zlib-ng. Also, update the "system brotli" consumption to use CMake's PkgConfig support. This provides us with a few benefits:

• We don't need to maintain a list of source files that we want to include from brotli.
• Consuming system vs in-tree brotli becomes much more similar as we use the same properties to specify targets and include directories.
• Using system brotli in NativeAOT comes easily when building against system brotli. No need for the nonportable.txt workaround as we have files on disk we can look for, just like zlib-ng.

Fixes #107020

[tmds]

@jkoritzinsky let me know when the PR is "ready", and then I will locally backport it to 9.0 and do some .NET builds to verify it fixes #107020.

[carlossanlop]

@akoeplinger @jkotas should we keep using the system brotli in mobile platforms and wasi/wasm like we did with zlib-ng? Why or why not?

[jkotas]

should we keep using the system brotli in mobile platforms and wasi/wasm

Does the system brotli exist on these platforms? Do we use it today?

[carlossanlop]

Does the system brotli exist on these platforms? Do we use it today?

I do not know if system brotli exists in those platforms but we do use it today with find_package, formerly located in extra_libs.cmake, but moved in this PR to here: #107166 (comment)

[jkotas]

We do not set CLR_CMAKE_USE_SYSTEM_BROTLI to 1 anywhere by default (different from zlib).

I think that system brotli does not exist on those platforms and we should be doing what we have been doing so far ie. use our bundled one. There is no other option.

[jkoritzinsky]

/azp run runtime-community, runtime-extra-platforms, runtime-nativeaot-outerloop

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[jkoritzinsky]

All failures look unrelated. Looks like we're good to go here!