This is a continuation of the effort to improve handling database object names. In this PR, in addition to object names expressed as strings, I'm introducing value objects that represent names.

Design Overview

Names

The interface for all names is Name. Currently, it has a single method toString(): string. There are various implementations of Name:

1. UnqualifiedName – to be used by the objects that exist within a table and thus cannot have a qualifier (e.g., column name).
2. OptionallyQualifiedName – to be used by the objects that exist within a database and optionally may exist in a different schema than the current one (e.g., table name).
3. GenericName – to be used for building ad-hoc SQL queries and eventually replace the Identifier class.

Named Objects

All database objects (the subclasses of AbstractAsset) will implement one of following interfaces:

1. NamedObject<N extends Name> – the ones that have a name of type N,
2. OptionallyNamedObject<N extends Name> – similar but the name is optional (implemented by indexes and constraints).

The interfaces conflict by design, since each class will have either a Name or an optional ?Name, not both.

Parsing Names

The Parser class introduced earlier has been broken down into a Parser<N extends Name> interface and one implementation per Name type. GenericNameParser parses the string into a generic name which may contain an arbitrary number of identifiers, and other parsers ensure that the name contains exactly as many identifiers as supported by the name.

Deprecations

Using the names that cannot be parsed is deprecated. Each database object will try to parse its name using the corresponding parser in _setName(), and if that fails, a deprecation will trigger. In DBAL 5.0, all this logic will move to the class constructors (see #6614).

As part of the implementation, the PR introduces two deprecated methods: AbstractAsset::createNameParser() and AbstractAsset::setObjectName() – they will be removed in DBAL 5.0 but aren't marked as internal because someone may want to use them to migrate their own implementation of AbstractAsset.

The chances that there are implementations of AbstractAsset outside of DBAL are very unlikely. Furthermore, the class itself is used in method signatures literally in a couple of places (it's more like a trait). Most likely, it will be removed in DBAL 5.0. With that said, I'm marking it as @internal for now.

Technical Challenges

NamedObject::getObjectName() and OptionallyNamedObject::getObjectName()

This method name sucks. A proper name would be getName(), but it's already taken and will be eventually deprecated. Unlike changing the parameter type in a method, I don't know of an easy way to change the return type w/o introducing a new method.

Next Steps

1. Add Name::toSQL(): string as a replacement for AbstractAsset::getQuotedName(). I could have done it right now but it wouldn't be used anywhere and would be untested.
2. Try to get rid of Schema\Identifier in favor of the corresponding Name on a per-case basis – this is where Name::toSQL() will be used.
3. Instead of using lowercased old names as object keys (e.g. for columns in the table) use the new keys and apply the normalization logic of the target platform. Thus, "id" and ID could co-exist for Oracle and IBM DB2 (reference).