WIP SIP-23

WIP PR to centralize discussion, accept improvements/tests/polish/docs/...

Everyone is welcome to look for the checkboxes/TODO items here and in the discussion below and take them on! If you're not sure where/how to start, just ask!

# Testing:
- [ ] syntax (infix notation, backquotes, quasiquotes, string interpolation?,...)
- [ ] subtyping
- [ ] implicits
- [ ] dependent method types
- [ ] type inference: not inferred for signatures, inferred when <: Singleton

# Spec/docs:
- [ ] include negated literal types in InfixType BNF (like prefixExpr)
- [ ] update syntax overview in spec
- [ ] spec the subtyping relationship between `ConstantType` / `LiteralType` and `scala.Singleton`.
- [ ] include SIP doc under spec/

# Type inference / type checking
- [ ] When inferring signatures, treat literal types like singleton types (i.e., don't infer them -- widen instead)
- [x] treat singleton type bound on type param same as Singleton bound (stopWidening when bounds exists _.isStable)
- [x] include fix for https://issues.scala-lang.org/browse/SI-8564 (idm.deconst)
- [ ] lub/glb

# Corner cases
- [ ] `val t: 1 = t`  (NOTE: t has value 0...)

# Design space
- [x] support negative literals
- [ ] Support Symbol literals --> challenge: desugars into Symbol.apply("symbol")
- [ ] Support class literals? (probably not)
- [x] Support ()? (I say 'no': () is not a syntactic literal, it's also too deeply ingrained to incorporate here)

# Feature interaction
- [ ] predicate on language flag (can't do this in parser, though -- use -Xsip:23 instead?)
- [ ] Update quasiquotes 
- [ ] Inconsistent representation of parse trees in different contexts
- [ ] scalap 
Sorry for being vague. I am thinking about the hidden assumptions in the code base regarding ()/Unit's current encoding. Parsing would not be hard, I agree. I'm more concerned about all the special casing it's received both in the batch and presentation compilers.