feat: auth Server should Support Client Registration Language Metadata

[nynymike]

Section 2.1 of OpenID Client Reg states:

Human-readable Client Metadata values and Client Metadata values that reference human-readable values MAY be
represented in multiple languages and scripts. For example, values such as client_name, tos_uri, policy_uri, logo_uri, and
client_uri might have multiple locale-specific values in some Client registrations.

To specify the languages and scripts, BCP47
[RFC5646] language tags are added to Client Metadata member names, delimited by a # character. The same syntax is used
for representing languages and scripts for Client Metadata as is used for Claims, as described in Section 5.2 (Claims
Languages and Scripts) of [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-registration-
1_0.html#OpenID.Core) [OpenID.Core].

If such a human-readable field is sent without a language tag, parties using it MUST NOT make any assumptions about the
language, character set, or script of the string value, and the string value MUST be used as-is wherever it is presented in a
user interface. To facilitate interoperability, it is RECOMMENDED that any human-readable fields sent without language tags
contain values suitable for display on a wide variety of systems.

• The highest priority claims are client_name and client_uri.

[qbert2k]

The Client metadata values: client_name (displayName), logo_uri (jansLogoURI), client_uri (jansClntURI), policy_uri (jansPolicyURI), and tos_uri (jansTosURI) now stores a JSON with values for multiple languages and scripts. For example:

MySQL, Couchbase, Spanner, etc.

client_name (displayName)

logo_uri (jansLogoURI)

client_uri (jansClntURI)

policy_uri (jansPolicyURI)

tos_uri (jansTosURI)

LDAP

LDAP has support for Language Tags

[nynymike]

This is an interesting feature. Let's make sure it gets listed in the internationalization section of the docs.

[yurem]

This #1482 problem related to this ticket.

LanguageTag should support read from DB and search in filters.

Why ORM layer should know how to handle specialized LanguageTag annotation? ORM has generic solution to work with JSON objects. Instead of this:

    @LanguageTag
    private LocalizedString logoUri = new LocalizedString();

We can use:

    @JsonObject
    private LocalizedString logoUri = new LocalizedString();

[qbert2k]

Hi @yurem
The LocalizedString is handled as JSON for MySQL, Couchbase, Spanner, etc.
But, LDAP has support for Language Tags so it is not handled as JSON.
That's the reason I have created a new annotation @LanguageTag to be able to perform a different treatment according to the case.

#1482