Fix NamespaceCache usage in System.Private.Xml.Linq

[hamarb123]

See https://github.com/dotnet/runtime/blob/main/src/libraries/System.Private.Xml.Linq/src/System/Xml/Linq/XLinq.cs#L181-L193 - it's intended to be mutated on Get so that it can cache the XNamespace object - the fields being marked readonly completely block all caching.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-xml
See info in area-owners.md if you want to be subscribed.

[stephentoub]

It looks like this occurred as part of moving these from being locals to being fields as part of d88ba5b#diff-b2b608017bdbacf5e4484368d6e1fcb03a9ea3b68f4aece41da253f72826acf9R908. Would they be better again as locals? I'm not sure why they were moved to be fields, but they're increasing the size of the ContentReader object by being here.
cc: @krwq

[krwq]

@hamarb123 please see @stephentoub's comments

[hamarb123]

@hamarb123 please see @stephentoub's comments

So, we want to move them to locals and pass them by reference to the methods?
Otherwise, they're just going to be called once making the caching pointless (like it is currently due to readonly) as all the current uses I looked at only call it once per method (of _eCache at least).

[hamarb123]

Except that won't work for the async methods... since it's a ref

[hamarb123]

So, it seems like previously all the stuff was done in ReadContentFrom - but now it's done in multiple sub-funtions, seemingly to support async. Previously the cache was declared in ReadContentFrom and used throughout the whole invocation. It seems like the same cache is still supposed to be used throughout the whole iteration, except that it was marked readonly (which accidentally broke the caching) - but it was moved to be a field, not a local, due to being easier to that being easier to work with async presumably. It looks like we could make it a local - for the sync version/s that would save a few bytes of allocation, and for the async version/s it would move the allocation - and just pass it by byref to the sync method that uses it (I assume we can do this in async?).

Please confirm the preferred approach @krwq @stephentoub

[hamarb123]

/ping @krwq @stephentoub ^

[stephentoub]

Ok, let's keep them as fields for now but revisit subsequently.