Add a getFieldValue() method to bypass typed data overhead for specific use cases

This needs at least some basic test coverage - load an entity, call this method to get a field value, then probably get the same thing via the regular field items and compare the values etc. but moving to needs review for the API.

Reminder we have a specific core use case in #2345611: [pp-1] Load user entity in Cookie AuthenticationProvider instead of using manual queries where as far as we know this is non-optional to enable that issue to happen without a performance regression. Until we fix the memory leaks in the field/typed data system it will also have some utility in contrib/custom code dealing with large numbers of entities but hopefully we can fix the memory leaks as well, since it'll be a pretty fragile solution to that problem (any call to $entity->get() will cause the memory leak again).

So I somewhat agree with #5 even though I spun this out of the other issue, but I was pretty shocked by the scale of the memory leak in typed data and this is out of desperation.

The page I'm testing against loads 500 entities + some references from those entities, and then gets some field values from them. It was taking 220mb of memory despite the entity LRU memory cache. With this MR and converting the ::get() calls to ::getFieldValue() the memory usage goes down to 60mb. So that is 170mb spent creating field item lists that can't be reclaimed. Not everything could be converted, that is probably another 10mb of memory leak according to some additional testing I did due to the remaining field item list creation.

That page is quite extreme but I think we could easily be seeing single or even double digit mb memory leaks on 'normal' pages with a decent number of entities (views listings, comments, paragraphs, LB + content blocks etc.).

My concern is that a method that bypasses field objects opens possibilities of inconsistent behavior and some things like computed properties or fields won't work.

This is true, we can probably throw a bad argument exception for computed fields quite easily. For properties it might be possible to get the typed data definition for the field and throw a bad argument exception in that case too, but in such a way we don't reference the type data and re-introduce the memory leak.

I'm hoping to keep going on the other two issues that should actually fix the memory leak - there is a probably viable fix for about half of it, found what I think is the root cause of the other half yesterday but don't have a viable fix for that yet.

One possible option here. Instead of adding this generically to the entity API, we could add it to a trait.

Then user module could use it in #2345611: [pp-1] Load user entity in Cookie AuthenticationProvider instead of using manual queries, and contrib/custom modules could use the trait if they want to, but it would make the entire thing opt-in.

User module could also even override the trait method to implement an allow list for specific field names too.

Discussed a bit with @berdir in slack, we came up with something like this:

1. Move it to a trait
2. Make it a protected @internal method on that trait.
3. User module can implement specific getter methods relying on the trait, so that it's not exposed as a public API anywhere else at all.
4. Custom entities could still use the trait - import the method as an alias, have a public method that calls it, that sort of thing.

MR now does what's in #8. The user entity and delete form changes are verbatim from #2345611: [pp-1] Load user entity in Cookie AuthenticationProvider instead of using manual queries, which means that issue would then only be about changing the cookie authentication handler.

By implementing this on the user entity we have some implicit test coverage now too.

Updated the issue summary.

Applied Alex's suggestion, and replied to the MR comment which I'm ambivalent about. Moving back to RTBC because that might mean no further changes, but also don't really mind if we eat the exception early either just not sure it's necessary here.