SIP-ZZ: Opaque type SIP (#884)

* Add sipzz.md to the repo.

This is an obviously wrong location. I put it here to avoid putting it
in a subtly wrong location instead.

* Add more newtype constraints

* Prohibit the use of `protected`

* Move wip sip to the sips folder

* Overhaul the previous specification

According to feedback from the SIP Committee, this commit adds changes
to the previous specification to fit type aliases, it describes the
technical details and some implementation details that I have dealt with
in my work-in-progress implementation.

The proposal is not yet ready, though. The motivation section is
missing, for example.

* Add motivation section

* Remove `alias` from opaque types

* Make opaque optional in the formalization

* Remove unnecessary sections + add conclusion

* Update 2017-09-20-opaque-types.md

* Here are some edits that I'm suggesting.

The main changes I made:

 1. I tried to flesh out the Logarithm example a bit.
 2. I removed unapply (which I think was misleading)
 3. I added some code addressing implicit enrichment.
 4. A bit of general clean up.

As far as my thoughts on the proposal:

 1. Even if there's no precedent for removing .asInstanceOf calls, I'd
    really prefer to completely erase those differences at
    compile-time if possible. I don't see a strong reason not to do
    this, and I'd like the encoding to resemble hand-written code when
    possible.

 2. I'm still somewhat bummed out about having to use implicit
    enrichment for value classes. I still think the proposal has a lot
    of merit, but I'd feel a bit better if we knew that enrichments
    were going directly to static methods, rather than relying on the
    complex machinery of value classes. That said, I still haven't
    benchmarked things, so it may be fine, but there's just a lot of
    machinery there that can be hard to reason about.

 3. I really like the in-companion / out-of-companion distinction for
    when opaque types become transparent. I think it should be easy
    for people to choose their level of opaqueness (i.e. people
    can choose when and how values can be lifted/lowered).

 4. I wonder if it would be useful to talk about how people could
    choose to define things like (Logarithm =:= Double) and/or (Double
    =:= Logarithm) if desired? I don't see any reason it wouldn't be
    possible to put these in implicit scope, but I haven't thought it
    through yet.

 5. Related to (4), we should ensure that conversions between the
    opaque type and the underlying type are always free. Consider:

      opaque type X = Int

      object X {
        def subst[F[_]](value: F[Int]): F[X] = value
      }

    In situations like tagging, the user will often want to be able to
    tag a very complex structure without having to reallocate, iterate
    over, inspect, or do anything. I want to be sure we can support
    constructions like this.

 6. I think we should drop multi-value opaque types. I don't like the
    idea of special-casing tuples, and there really isn't any other
    good syntax I can think of for them. The multi-value proposal
    really leaned more heavily on having built-in static extension
    methods, which the current proposal doesn't. They were always a
    bit of a long-shot due to their similarity with the existing value
    classes (as far as auto-boxing/unboxing, bridge methods, etc.)

Thanks for working on this! I'm sorry I'm leaving this so late, there
are likely further improvements we could make but I don't see them
now. I do feel like things are relatively well-scoped as-is.

* Remove further optimizations section

* Add technical clarifications from Erik's feedback

Author: jvican