Move JNDI DataSource to separate module

[ppkarwasz]

We move the DataSource connection source to a new module log4j-jdbc-jndi.

The main rationale for this change is to remove the optional dependency on log4j-jndi from log4j-jdbc.
This change forces users to opt-in for the JNDI DataSource by adding log4j-jdbc-jndi to their classpath.

After this change, the log4j-jdbc artifact contains:

• the JDBC Appender,
• a connection source based on DriverManager,
• a connection source based on a static factory method.

Closes #1914

[vy]

Overall, LGTM.

Question: Is the DBCP detail of our log4j-jdbc* modules well-hidden? If so, I suggest

1. Removing all of its public mentions
2. Switching to HikariCP¹ instead

¹ HikariCP is, both performance- and feature-wise, a clear winner against any other alternative in the market as of today. It is the default JDBC connection pool in both Spring Boot 2 and Spring Boot 3.

Of course I am not suggesting this for this PR. But I feel like this is an okay place to discuss it.

[ppkarwasz]

Question: Is the DBCP detail of our log4j-jdbc* modules well-hidden? If so, I suggest

1. Removing all of its public mentions

2. Switching to HikariCP instead

DBCP has a nice feature, that justifies its pool of aficionados: you can register a pool with the JDBC driver and retrieve it later using a jdbc:apache:commons URI.

Note that until #1916 is fixed, all pools perform the same: only a single connection is used at each time.
The main problem is the synchronization of AbstractDatabaseManager. Removing it might technically not be a breaking change, but it is a very disruptive one.