perf: opt-in reflection cache via ApplicationContext; promote internal API to public

[Copilot]

Addresses the opt-in request from googleapis/google-api-dotnet-client#3118 review.

Motivation

The parent PR (googleapis#3118) caches PropertyInfo results to fix the DestroyScout finalizer pathology documented in #3112. The maintainer requested that caching be opt-in rather than always-on, citing concerns about unbounded cache growth and ConcurrentDictionary overhead.

Design decision: reuse ApplicationContext instead of a new class

Rather than introducing a new ReflectionCacheSettings class (adding permanent public API surface), this PR adds EnableReflectionCache to the existing ApplicationContext — the library's established pattern for app-wide startup settings (cf. ApplicationContext.RegisterLogger). This:

• Adds zero new public types — a single property on an existing class
• Is easier to obsolete later — if caching becomes the default, the property can be [Obsolete]-d without removing an entire class (consistent with how this library already handles API evolution, e.g. IClock.Now, GoogleClientSecrets.Load, ConfigurableMessageHandler.UnsuccessfulResponseHandlers)
• Follows the library's own precedent — ApplicationContext is already referenced by ParameterUtils, RequestBuilder, ConfigurableMessageHandler, and BackOffHandler for exactly this "set once at startup" pattern

A note on the reviewer's concerns

For the record on the technical points raised in the review:

• "400+ libraries in CI" scenario: The cache is per-process and keyed by Type. A CI testing libraries in separate processes would never accumulate all types in one cache. Even in the extreme single-process case, ~20K entries is trivial memory. The current no-cache behavior is actually "unbounded" in a worse way — it creates unbounded transient PropertyInfo arrays and IL stubs per request, which is exactly what triggers the GC/finalizer pathology in Performance: Reflection in ResumableUpload and ParameterUtils causes intermittent long response delays. googleapis/google-api-dotnet-client#3112.
• ConcurrentDictionary bottleneck: GetOrAdd on a cache hit is a Volatile.Read — no lock is taken. Cost is ~20–50 ns. Without the cache, Type.GetProperties() + GetCustomAttribute() runs per request at 10–100 µs. The cache is strictly faster on every code path after the first call. This is the standard pattern recommended by Microsoft and used internally in ASP.NET Core, EF Core, and System.Text.Json for reflection caching.

Changes

File	Change
ApplicationContext.cs	Added EnableReflectionCache property (default false); updated class summary; Reset() now clears the flag
ReflectionCache.cs	References ApplicationContext.EnableReflectionCache; public; extracted ComputeProperties; conditional cache path
PropertyWithAttribute.cs	Promoted to public; comprehensive XML docs
ParameterUtils.cs	InitParametersWithExpansion promoted internal → public; stale InternalsVisibleTo remark removed
AssemblyInfo.cs	Removed InternalsVisibleTo("Google.Apis", …)
Tests	All references updated; tests for both cached/uncached modes; proper setup/teardown

Usage

// At application startup, before any API calls:
ApplicationContext.EnableReflectionCache = true;

Default behavior is unchanged — no caching, no new overhead.