Describe the bug

I noticed while working on #41929 that:

• For JDBC datasources, we don't even try to connect to a database if the JDBC URL is not set
• For Reactive datasources, we default to localhost and a DB-specific port if the Reactive URL is not set

This is inconsistent, and IMO the reactive behavior is at best unnecessary, at worst dangerous:

1. In dev mode, people should generally use dev services, so the URL will always be set, so this is irrelevant.
2. In prod mode, people will most likely need dedicated config -- specific DB name at the very least, and most likely authentication.
3. In either dev mode or prod, people might not want to connect to some arbitrary, default DB that just happens to be there, and potentially start messing with the database schema (e.g. with Hibernate).

What's more, this default is not documented at all:

I would suggest we align reactive datasources on the behavior of JDBC datasources.

Expected behavior

Reactive datasources should behave similarly to JDBC datasources when the reactive URL is unset. Or, to be precise, they should behave similarly to JDBC datasources after #41929 gets fixed:

1. Runtime startup should fail if such a datasource is statically injected.
2. Dynamic retrieval of such such a datasource through Arc should throw an exception.
3. Such a datasource should not appear in health checks.

Actual behavior

1. Runtime startup does not fail if such a datasource is statically injected.
2. Dynamic retrieval of such such a datasource through Arc does not throw an exception.
3. Such a datasource appears in health checks, with a DOWN status.

How to Reproduce?

I will add tests in #41929; I may send a separate PR with just the tests.

Output of uname -a or ver

No response

Output of java -version

No response

Quarkus version or git rev

No response

Build tool (ie. output of mvnw --version or gradlew --version)

No response

Additional information

No response