Start the 2.x development series

This preemptively bumps ImageJ to 2.0.0-beta-8, which now covers only
the net.imagej:imagej artifact that ties together all ImageJ components.

It also removes all the obsolete ij-* components which were part of
imagej.git's previous multi-module build.
Update comment describing the version properties
Remove groupId properties

The rationale is as follows:

1) It is more confusing for newcomers to Maven to see
   "<groupId>${foo.groupId}</groupId>" rather than simply
   "<groupId>org.foo</groupId>" as is done for non-SciJava-managed
   dependencies.

2) IDEs such as Eclipse have built-in support to search for and add
   dependencies, but this support necessarily does not "do the right
   thing" with respect to the dependency's groupId property. Users
   must always manually edit their POM for that.

3) We were inconsistent with which components had a groupId property,
   and which did not. If we are going to have groupId properties, we
   should have them for every single managed component to avoid
   violating the Principle of Least Astonishment.

4) Further, if we have a property for each component's groupId, we
   should also (again, for consistency) have one for each component's
   artifactId as well. And the same arguments above -- especially
   items 1 and 2 -- apply for artifactId properties as well. And if
   we were to create an artifactId property for each artifact, it
   would be unfortunate as soon as one of the artifactIds changed,
   since we would be left with a foo.artifactId variable whose value
   does not equal "foo" anymore.

5) Having such groupId and artifactId properties in the pom-scijava
   parent adds complexity, which must always have sufficient
   justification. In this case, I do not think the benefit of
   making some theoretical future group or artifact rename more
   transparent for downstream consumers (and only those who "did the
   right thing" and manually edited their POMs to use the properties)
   outweighs all the disadvantages listed above.

   (Another use case -- that someone wants to replace all
   dependencies of a given groupId with ones from their own
   groupId -- is rather unlikely and inflexible.)