M1 versioning including Boost BOM issues/cleanup

[scottkurz]

1. Let's move the plugin version from 0.1.3-SNAPSHOT to 1.0-M1-SNAPSHOT
2. Let's version all BOMs together with the plugin itself, ideally via property if that works.
3. For MicroProfile API BOMs, let's start by just importing the existing org.eclipse MP BOMs. That may be all we need to do to start.
4. Also for MicroProfile API BOMs

• let's import the runtimes BOM directly (don't rely on the import via EE BOM import)
• if we still have need to pull in EE BOM, it needs to be via import... we shouldn't just put a BOM in depMgmt as a non-import dependency. (Now I don't see where I thought we were doing this, maybe I imagined it).

5. For the boosters: don't import API BOMs. Not repeating ourselves isn't worth making the dependency graph harder to understand. Maybe we can avoid not repeating the version in some other way within this entire repo, but if not, just copy the property somewhere.
6. Should boost BOMs have a different groupid than boosters?

[scottkurz]

We could also use this for:

1. renaming groupid to a "microshed" group id
2. Using the new io.openliberty.tools liberty-maven-plugin

[scottkurz]

Resolved by #366