Figure out how to port shaded netty to native

Camel components known to pull an embedded Netty:

* Kudu https://github.com/apache/camel-quarkus/issues/1669
* Couchbase https://github.com/apache/camel-quarkus/issues/1188
* HBase https://github.com/apache/camel-quarkus/issues/1648

In case of Kudu, I simply copied the substitutions and deployment code from quarkus-netty, see https://github.com/apache/camel-quarkus/pull/1667 but this approach is hard to maintain. It would be even more hard to do it for n separate embedded Netties.

As seen in case of Kudu asking the third party lib to stop shading netty may get refused for valid reasons.

Ideally both the substitutions and deployment BuildSteps should be made to accept the shaded package prefix parameter somehow. I think it is rather easy in case of the BuildSteps (we'd produce some sort of ShadedPackagePrefixBuildItem and NettyProcessor would consume it). It is a bit harder in case of the Substitutions. They'd have to be generated either on source code or bytecode level.

Any other ideas?

Start by reviewing the existing substitutions and deployment BuildSteps copied from quarkus-netty for the Kudu case, then inspect how NettyProcessor consumes build information. Compare the Kudu, Couchbase, and HBase examples and determine how shaded package prefixes could be represented for both BuildSteps and substitutions. Done means a maintainable approach supports embedded, shaded Netty packages without copying separate integration code.

Written by the indexing model from the issue text.