Allow running CLI in dev mode, without overwriting quarkus version

[mocenas]

Summary

Create an option for CLI based application to run and not have their quarkus version overwritten. Using up-to-date quarkus is usually a good thing, but for testing CLI stuff like --stream=3.x and quarkus update I want to run the app with the version that is specified in the pom and not overwrite it.

This PR should cause no problem to existing stuff, as defaults are the same. It just allows to change this behaviour to run quarkus apps without setting quarkus version as their parameter. Example how to use it is new test.

Please check the relevant options

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Dependency update
• Refactoring
• Release (follows conventions described in the RELEASE.md)
• Breaking change (fix or feature that would cause existing functionality to change)
• This change requires a documentation update
• This change requires execution against OCP (use run tests phrase in comment)

Checklist:

• Example scenarios has been updated / added
• Methods and classes used in PR scenarios are meaningful
• Commits are well encapsulated and follow the best practices

[fedinskiy]

There is one only thing (see below). I would prefer to have it changed, but it is not a blocker

[fedinskiy]

This lambda is a bit hard to comprehend (especially since s parameter is not used). Please, consider, whether this api can be changed to improve readability

[mocenas]

I agree, this lambda is ugly. Thing is, it is two level lambda - basically a reduction for typical problem "how to fix a square thing into round hole". This lambda actually provides instance of ManagedResourceBuilder, which takes just one parameter(ServiceContext) but we need to instantiate CliDevModeLocalhostQuarkusApplicationManagedResource which has two parameters (ServiceContext, QuarkusCliClient).

I tried other approaches like some magic with OOP and interface inheritance or passing just class reference. All of them either hit some java limitation, or have really nasty implementation.

To conclude I found no better way how to solve this, that would not require greater changes in already existing stuff. I at least renamed "s" variable to managedResourceBuilder so it is somehow cleaner what is going on.