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!

- [ ] tests

- [ ] 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/

- [ ] 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

- [ ] `val t: 1 = t`  (NOTE: t has value 0...)

- [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)

- [ ] 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 
Thanks for pointing this out. We assumed that `()` is a literal syntax-wise and typed it accordingly in our strongly typed tree api which one might consider to be a natural way to model Scala code (considering the fact that `()` is still called unit literal.)

If support for unit literal is costly we might have to re-do this part of our trees. But I'm not sure what exactly are the costs you are talking about.  Grammar just needs another case around https://github.com/adriaanm/scala/pull/12/files#diff-c067e953d98d0b8fb993aeae8bdb0bd4R26 that will allow "()" as a valid type. I don't think that this will cause any ambiguities apart from () => T which can be resolved in favour of current interpretation as Function0.

I don't mind contributing required changes to the parser/grammar.