Dev mode fails when using "Maven CI Friendly Versions" and Quarkus version override via -D

[famod]

Describe the bug
(Warning: This is a rather strange edge-case.)

When using Maven CI Friendly Versions (e.g. <version>${revision}</version>), dev mode seems run into an inconsistent state when the Quarkus version is overridden via -D... (e.g. root pom defines 1.3.2.Final and you want to test 1.4.0.Final or 1.4.1.Final) and a submodule dist is "selected" via mvn -f dist ... (or via cd dist).

In this case, if the module contains a simple REST controller (e.g. HelloResource) with an injection of another simple bean (which resides in the same package, e.g. AnotherHelloBean), dev mode will fail with AmbiguousResolutionException because it finds the latter twice:

Caused by: javax.enterprise.inject.spi.DeploymentException: Found 2 deployment problems:
[1] Ambiguous dependencies for type com.github.famod.modmono_quarkus.dist.AnotherHelloBean and qualifiers [@Default]
        - java member: com.github.famod.modmono_quarkus.dist.HelloResource#bean2
        - declared on CLASS bean [types=[com.github.famod.modmono_quarkus.dist.HelloResource, java.lang.Object], qualifiers=[@Default, @Any], target=com.github.famod.modmono_quarkus.dist.HelloResource]
        - available beans:
                - CLASS bean [types=[com.github.famod.modmono_quarkus.dist.AnotherHelloBean, java.lang.Object], qualifiers=[@Default, @Any], target=com.github.famod.modmono_quarkus.dist.AnotherHelloBean]
                - CLASS bean [types=[com.github.famod.modmono_quarkus.dist.AnotherHelloBean, java.lang.Object], qualifiers=[@Default, @Any], target=com.github.famod.modmono_quarkus.dist.AnotherHelloBean]

This does not happen when 1.4.1.Final is set in root pom.

Expected behavior
There should be no difference between setting the version in root pom.xml or via -D....

Actual behavior
-D... causes a bean class in the same module being found twice preventing dev mode from starting properly.

To Reproduce
Steps to reproduce the behavior:

1. Clone https://github.com/famod/modmono-quarkus.git
2. Switch to branch quarkus-8832-ci-friendly-quarkus-update
3. Verify that dev mode works with the initial version 1.3.2.Final:

   mvn clean install -DskipTests && mvn quarkus:dev -f dist
   

4. Rebuild project and restart dev mode with version 1.4.1.Final (should fail):

   mvn clean install -DskipTests -Dquarkus.version=1.4.1.Final && mvn quarkus:dev -f dist -Dquarkus.version=1.4.1.Final
   

5. (optional) Set 1.4.1.Final in pom.xml, rebuild and start dev mode (should be ok)

Configuration
n/a

Screenshots
n/a

Environment (please complete the following information):

• Output of uname -a or ver:
  MINGW64_NT-10.0-18363 W4DEUMSY9003463 3.0.7-338.x86_64 2019-11-21 23:07 UTC x86_64 Msys
• Output of java -version:

  openjdk version "11.0.6" 2020-01-14
  OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.6+10)
  OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.6+10, mixed mode)
  

• GraalVM version (if different from Java): n/a
• Quarkus version or git rev: 1.4.1.Final
• Build tool (ie. output of mvnw --version or gradlew --version): Apache Maven 3.6.3

Additional context
This problem totally led my astray while trying to test #8794. Before creating this issue I had a detailed chat on Zulip with @aloubyansky.
My guess is that Quarkus does not consider system properties when handling the Maven poms to support "Maven CI Friendly Versions".

Btw, the respective bean is even found three times when using mvn -f ./dist ... (notice the leading dot). I guess this has something to do with a bug in 1.3.2 (and 1.3.1) where this pattern causes the bean to be found two times (even without "Maven CI Friendly Versions"). That bug is not present in 1.4.0+ anymore.

[quarkusbot]

/cc @quarkusio/devtools

[aloubyansky]

1. System properties aren't propagated to the dev mode process;
2. Certain fixes are necessary in the model interpolation.
   I've created a branch for fixing this https://github.com/aloubyansky/quarkus/tree/revision-version-devmode
   I did come up with a simpler project that would fail. The branch referenced above fixes it. But not yet the reproducer from the original description.