As it stands we support two kinds of PgTypeInfos: one directly wrapping a converter and one to facilitate delayed converter resolution (PgConverterResolver). Unfortunately both return the same information from different places today, and it must generally be cached for different lengths of time as well. This causes us to have a bunch of accidental complexity (additional types and state) and duplicated logic to work on 'these things that must not be forgotten or uncommonly used things go wrong' for the case where converter resolver type infos are passed in.

For example, the public PgConverterResolution, the internal PgConverterResolverInfo and even to some extent the internal ColumnInfo and ColumnInfo for the nested reader exist because we need to handle that split (where an info could either be concrete or a delayed resolution) all the way down at the actual read and write call sites. Just to paint a picture, just Npgsql alone is expected to implement this split correctly in all the following places: NpgsqlParameter, NpgsqlBinaryImporter/NpgsqlBinaryExporter, NpgsqlDataReader, NpgsqlNestedDataReader, ReplicationValue, CompositeConverter, and ObjectConverter. But also any plugin that wants to compose type infos to write some larger data type has to deal with this.

Unsurprisingly it would be much better if all of this could be centralized, and I recently got inspired to finally tackle this after reviewing #6005. The feature that the linked PR intends to enable deals with all the same complexity around value dependent writing to provide general DataTable to pg (table) composite support, which they would like to release as a plugin. Today it's practically impossible to do that correctly, due to the knowledge required to replicate that split correctly for the composed, field level, type info handling needed for composites.

To improve the status quo this PR starts by making PgTypeInfo abstract and adds a new derived type to the hierarchy: PgConcreteTypeInfo, this will be the authoritative info source that gets used during reads and writes, no more split at all those sites. We also rename PgConverterResolver to PgConcreteTypeInfoProvider and PgResolverTypeInfo to PgProviderTypeInfo. These renames align the types with what they operate on and gets rid of the overloaded resolver/resolution moniker, which will now just relate to IPgTypeInfoResolver. This has been a change I've been meaning to make ever since we released 8.0, at the time it was just too late in the cycle to rework and think all of this through properly.

Shifting the PgTypeInfo hierarchy into this direction allows us to merge the concrete/resolver split back into one source after field and value binding. For most cases nothing really changes on the mapping authoring side except the type identity: mappings that don't rely on a resolver will now return PgConcreteTypeInfo. As most mappings rely on mapping.CreateInfo to create their PgTypeInfo we are able to change this in a binary compatible way (and if the PgTypeInfo constructor does happen to be used today, rare even in Npgsql, a small change to new up PgConcreteTypeInfo instead is sufficient).

The PgResolverTypeInfo and PgConverterResolver changes are more breaking, though also easily adapted to. Regardless, no users of this api surface have been found after a thorough github search (searching for any direct references to these types); it's also quite unlikely private implementations exist. Additionally all of this api surface is marked experimental, and while I don't advocate for doing impactful breaking changes just because we can, it is intended to give us that kind of wiggle room.

Finally, where current mappings do use the PgProviderTypeInfo functionality (like bitstring fields or datetime values) the provider implementation (previously converter resolver) will become responsible for returning *cached* PgConcreteTypeInfo instances. The unwillingness to demand this caching was the original sin that lead to the split, and why the PgConverterResolution return type was a struct.

At the time it was unclear to me whether we could always cache the returned results (which otherwise would lead to an unavoidable allocation on every bind) as the providers may act on ever changing values. In practice all implementations we authored end up caching their produced converter instances already. And at this point I'm also convinced that any useful implementation classifies fields and values into a few well known categories it has converters for, and for which it is never a problem to cache the required variations.

The total work is split across PRs to make reviewing more practical. This PR mostly contains the nominal and type level restructuring, while the follow up PR will use these changes to actually deliver the simplification of the call sites. A final PR should provide the public surface that we can recommend to plugin authors interested in working with POCO or dynamic (e.g. datatable) conversions that interact correctly with nested field and value binding.