The refactor in this commit is driven by the work in the subsequent
commit for issue scalacenter#659 (creating a Scaladex badge that supplies
concise info on supported Scala versions). The key word there is
'concise' - given the many Scala artifacts that can be published for
a single artifact version (the matrix of Scala language version, the
platform - Scala JS/Native/SBT - and the platform version), achieving
a concise summary requires a lot of grouping by those properties.

Grouping by Scala `LanguageVersion` was easy enough, but grouping by
platform & platform version was harder, as there wasn't any existing
class to represent that. Consequently, I introduced the concept of a
'platform edition' (eg 'Scala JS 0.6', or 'Scala Native 0.4'), which
is composed of two values:

* targetType (Scala JS, Scala Native, or SBT)
* platform version (eg the version '0.6' or '1.0' of Scala JS)

...this is like a `ScalaTarget`, but without the Scala Language
version that `ScalaTarget` includes (eg a `ScalaTarget` is
specifically compiled for, eg, _Scala 2.11_ on Scala JS 0.6).

Having introduced the concept of `PlatformEdition`, it made sense to
redefine relevant `ScalaTarget`s in terms of that - to do this meant
moving several ad-hoc methods from the companion objects of
`ScalaTarget` implementations (ie `ScalaJs`, `ScalaNative`,
`SbtPlugin`) to the corresponding `ScalaTargetType` implementations
and making them more widely available, by declaring them in the new
`PlatformVersionedTargetType` trait, removing duplication for this
existing code:

* producing a String `render` value for platform names
* checking validity of platform versions.

As result most of the `ScalaTarget` companion objects were now empty
and could be deleted.

Another smaller change was prompted by the upcoming need to identify
a `ScalaTargetType` by name (when the user specifies it as a query
string parameter). To do that, you need a full list of
`ScalaTargetType`s, and then you can also use that list to create an
`Ordering[ScalaTargetType]`

Also tidied up various tests that were creating their own platform
version constants (as I was already moving equivalent constants from
`ScalaTarget` companion objects to `ScalaTargetType` objects)

Fixes scalacenter#659 - adding
support for a badge that summarises, for a given artifact, which versions
of Scala it supports (and what the latest artifact version is for each
of those Scala versions).


```
$ curl --silent -I http://localhost:8080/typelevel/cats/cats-core/latest-by-scala-version.svg | grep Location
Location: https://img.shields.io/badge/cats--core-0.9.0_(Scala_2.12,_2.11,_2.10)-green.svg?

$ curl --silent -I http://localhost:8080/typelevel/cats/cats-core/latest-by-scala-version.svg?targetType=Js | grep Location
Location: https://img.shields.io/badge/cats--core-0.9.0_(Scala_2.12,_2.11,_2.10_--_Js_0.6)-green.svg?
```

Prompted by scalacenter#660 (comment),
this is a testcase for when Scala platform editions are not available for
all cited Scala versions. In this situation, there are a few options for
what the badge text could be:

* Over promise: `7.1.0 (Scala 3.0.0-M3, 2.13 - Native 0.4+0.3)`, which
  incorrectly implies that there's a `3.0.0-M3` version for `Native 0.4`.
* Provide full detail:
  `7.1.0 (Scala 3.0.0-M3 - Native 0.4, Scala 2.13 - Native 0.3)`.
* Omit platform versions that don't have full support for the listed
  Scala language versions: `7.1.0 (Scala 3.0.0-M3, 2.13)`.

The endpoint `latest-by-scala-version.svg`, is intended to list all
supported Scala versions, with the latest artifact version against them,
and giving that information concisely takes priority over providing
completely comprehensive information about the differing versions of the
Scala platforms. It's also best not to over-promise, so of the three
options I think the last is the best.

* Switch from case class to function that encloses intermediate states
* Rename `ArtifactScalaVersionSupport` to `BadgesSupport` as it's only
  used by the `Badges` class

scalacenter#660 (comment)
scalacenter#660 (comment)

I've overloaded the `summaryOfLatestVersions()` method so the tests can
have a version of the method that accepts a
`Map[SemanticVersion, Seq[ScalaTarget]]` - it makes the tests more
concise.