Introduce RuntimeCamelContextCustomizerBuildItem to allow to customize the camel context before it is started

[lburgazzoli]

[ ] An issue should be filed for the change unless this is a trivial change (fixing a typo or similar). One issue should ideally be fixed by not more than one commit and the other way round, each commit should fix just one issue, without pulling in other changes.
[ ] Each commit in the pull request should have a meaningful and properly spelled subject line and body. Copying the title of the associated issue is typically enough. Please include the issue number in the commit message prefixed by #.
[ ] The pull request description should explain what the pull request does, how, and why. If the info is available in the associated issue or some other external document, a link is enough.
[ ] Phrases like Fix # or Fixes # will auto-close the named issue upon merging the pull request. Using them is typically a good idea.
[ ] Please run mvn process-resources -Pformat (and amend the changes if necessary) before sending the pull request.
[ ] Contributor guide is your good friend: https://camel.apache.org/camel-quarkus/latest/contributor-guide.html

[lburgazzoli]

@jamesnetherton I see the observability example failing, whereas the integration tests don't:

2020-05-12T14:32:54.9011253Z [ERROR] Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 9.72 s <<< FAILURE! - in org.acme.observability.ObservabilityTest
2020-05-12T14:32:54.9012133Z [ERROR] metrics  Time elapsed: 0.036 s  <<< FAILURE!
2020-05-12T14:32:54.9012380Z java.lang.AssertionError: 
2020-05-12T14:32:54.9012618Z 1 expectation failed.
2020-05-12T14:32:54.9012852Z Expected status code <200> but was <204>.
2020-05-12T14:32:54.9013047Z 
2020-05-12T14:32:54.9013270Z 	at org.acme.observability.ObservabilityTest.metrics(ObservabilityTest.java:38)

mind having a look ?

[lburgazzoli]

ok so I found the reason and it has to do about when the various bits are wired to the camel context