Keep Base64 polyfills when Microsoft.Bcl.Memory is referenced

[SimonCropp]

Bug

Base64Polyfill.cs was guarded with #if FeatureMemory && !RefsBclMemory && !NET11_0_OR_GREATER. Microsoft.Bcl.Memory supplies Base64Url, Index and Range, but it does not (and cannot) add the net11 static members to System.Buffers.Text.Base64. So referencing that package silently removed 13 polyfills (Base64.EncodeToString, EncodeToChars, DecodeFromChars, TryDecodeFromChars, GetEncodedLength, ...) with nothing replacing them. PolyfillLib references Microsoft.Bcl.Memory below net9, so the compiled library shipped without them on those targets.

The same !RefsBclMemory condition around Base64Usage in src/Consume/Consume.cs hid this: ConsumeLib compiles that file against PolyfillLib and inherits the package reference, so the usage was compiled out exactly where the API was missing.

Fix

Remove !RefsBclMemory from the Base64Polyfill.cs guard and from the Base64Usage guard in Consume.cs.

Test

These are compile-time consumers, so the coverage is compilation:

• Consume.cs Base64Usage is now compiled by ConsumeLib / ConsumeEmbeddedLib against PolyfillLib on every target
• ConsumeBclMemoryNoResolve/Consume.cs (source-only Polyfill plus a Microsoft.Bcl.Memory reference) now calls Base64.EncodeToString, Base64.DecodeFromChars and Base64Url.EncodeToString

Before regenerating src/Split both failed with CS0117: 'Base64' does not contain a definition for 'EncodeToString' (and the other members). After the fix ConsumeBclMemoryNoResolve, ConsumeBclMemoryExcludeCompile, ConsumeConsumeBclMemory (which builds ConsumeBclMemory), ConsumeLib, ConsumeEmbeddedLib and Consume build on all their target frameworks with 0 warnings.