Normalize camel and camel-quarkus dependencies

[nicolaferraro]

Let's take a hello world integration. There are some commands that theoretically should do the same thing, but they don't:

• kamel run hello.yaml -d camel:jackson: adds org.apache.camel:camel-jackson
• kamel run hello.yaml -d camel-quarkus:jackson: error in the CLI, but works as next one if set manually in the integration
• kamel run hello.yaml -d camel-quarkus-jackson: adds org.apache.camel.quarkus:camel-quarkus-jackson and transitively org.apache.camel:camel-jackson

I think that we should treat camel: and camel-quarkus: as synonyms, as there's no reason why one would like to add the camel component without the quarkus extension, given that we only have quarkus as runtime. People can still use mvn: if they want to use a specific lib. We can keep both for compatibility, but with the same meaning.

This problem is also evident in Kamelets, where we need to use camel-quarkus: and mark the Kamelet as requiring Quarkus just because dependency formats are distinct.

cc @astefanutti , @lburgazzoli wdyt?

[astefanutti]

Totally makes sense. Considering the runtime as an implementation detail, that should not resurface to the end-users as much as possible, camel-quarkus should ideally be dropped and only camel: be kept. We can keep it around for backward compatibility reason, but have it replaced all around. Also, maybe we can go a step further and shorten camel:aws2-sqs with just aws2-sqs.

[lburgazzoli]

On the subject I've opened an issue on camel-quarkus as we can certainly have some way to detect and support both camel-quarkus- vs camel- or even a shorter form, but for a safer approach would be to add such info in the catalog and do not rely on duck typing.