Remove the boilerplate associated with the new design (and more)

[szeiger]

• The respective CC types are exposed (to protected[this]) through
  aliases IterableCC, SortedIterableCC, MapCC and SortedMapCC
  in the respective Ops traits, plus a BitSetC for the shared
  BitSetOps trait.

• This allows defining fromSpecificIterable, newSpecificBuilder
  and empty (for all but Iterable) in the respective collection
  traits Iterable, SortedSet, Map and SortedMap (not in their
  Ops traits) where the CC type is visible and set to a concrete
  type but can still be refined in subtypes. This gives us a valid
  implementation until a concrete collection type with a refined CC
  gets defined. In this case the inherited implementations have the
  wrong type, so the user is forced to override them.

• Implementations of fromSpecificIterable, newSpecificBuilder and
  empty can be removed from almost all collection implementations
  except the ones where they need to be refined even further than what
  a factory can provide (e.g. IntMap, PriorityQueue).

• Factories are generally overridden in abstract collection types that
  refine a CC (e.g. Iterable -> Seq -> immutable.Set ->
  immutable.IndexedSeq) so that concrete implementations without
  further refinement do not need to override them.

• DefaultMap is deprecated because there is no more boilerplate left
  that it could implement.

• sortedFromIterable, mapFromIterable and sortedMapFromIterable
  are treated the same way as fromIterable. They are implemented as
  inline final calls to the respective factory method.

Fixes #335

[julienrf]

Interesting! It goes beyond what I thought we could achieve :)

I’m a little bit worried of introducing new abstract types. Even though they are defined as protected, they leak to the public API via iterableFactory: IterableFactory[IterableCC], etc.

[julienrf]

typo: know => now. Also CC[E] => CC[B]

[szeiger]

I'll update these comments to make more sense for the new design.

[julienrf]

Here what’s the difference with the base implementation?

[szeiger]

This is wrong and was equally wrong before. We need to build using elemTag here.

[julienrf]

You will have to update collections-contrib as well.

[lrytz]

This is really great!!

[szeiger]

The new type members are unavoidable. They are merely aliases for existing type parameters, not abstract types. They ensure that the collection traits can declare the correct return types depending on some CC even though CC is fixed at that point (but can be covariantly refined). This allows us to provide concrete implementations even though the types can be changed in incompatible ways in subclasses.

This started as a plan B after running into scala/bug#10725 but even without that problem my original approach would not have worked because concrete definitions win over abstract ones. It might still work in Dotty if it has gotten rid of that rule in favor of proper type unification.