Use a safer fresh name, and construct trees more idiomatically.

These changes were all suggested by @retronym.
Some very small test cases for type lambdas.
Update documentation to make it clear [] => ... is invalid.

As @adriaanm pointed out, the grammar comment was wrong. Type lambdas
require at least one type paramter.

Even though the parser fails to accept `[] => ...` at an earlier point,
I added a bit of error-checking to make sure that we never accept such
a construction (at least until it has an accepted use/meaning).
Do not check for the presence of some SIP-18 feature imports

Features which usually issue warnings or errors if the
language.existentials, language.higherKinds and
language.implicitConversions implicits are not in scope will no longer
do so.
Removed unnecessary failing test
Merge pull request #74 from propensive/sip18-noops

Do not check for the presence of some SIP-18 feature imports
Merge pull request #73 from non/topic/typelambda-cleanup-v0

Topic/typelambda cleanup v0
[WIP] SIP-23 Parse `Literal` as `SimpleType`

This requires -Xexperimental in 2.11.x.

Update spec.

TODO:
 - test!
 - include SIP as spec addendum
 - don't predicate on -Xexperimental -- introduce -Xsip:23?

Notes:
 - `()` is not a literal, neither are `Symbol`s
[WIP] SIP-23 LiteralType: 42 and friends

`LiteralType` is a `SingleType` with a literal for its path.
With an example: `1` is to `p.type`, as `1` is to `p`.

`lit` is the most precise type for an expression known to evaluate to `lit`.
Note that we cannot constant fold the expression to `lit`, since it may have a side effect.

`ConstantType(c)` is the type of an expression that can be constant folded to `c`.

When an expressions should not be constant folded, the corresponding `LiteralType`
is created: `ConstantType(c).deconst == LiteralType(c)`
(this is where all `LiteralType`s originate, except for unpickling).

`typedLiteral` always infers a `ConstantType`, which is subsequently
`deconst`ed or `widen`ed where necessary (see `widenIfNecessary`).
In short, only `final val`s may have `ConstantType`s, and
`widen`ing is required to ensure that a path is stable and accessible (roughly speaking).

When checking subtyping, this invariant is useful: `LiteralType(c).widen == c.tpe`.

TODO:
  - test! (subtyping, type inference, type tests, patmat, dependent method types)
  - fully predicate implementation on -Xsip:23
  - is it safe to reduce LITERAL in pickler?
[WIP] SIP-23 equality test for singleton type <:< AnyVal

test case:

```
val y: 5 = 5
def g(x: Int) = x match {
  case _: y.type => 0
}
```
[WIP] SIP-23 fix doc comment in parsers
SI-8564
Add some basic smoke tests for SIP-23.
SIP-23 Account for literal types in varargs translation

Before:

	sandbox/test.scala:2: error: type mismatch;
	 found   : Array[1]
	 required: Array[Int]
Add LiteralType to JavaUniverseForce, backward, and forward bincompat.
WIP SI-5103 avoid widening TypeVar <: Singleton

TODO: deriving this from type param bounds is not the best way,
should consider all constraints that we encounter

scala> def stable[T <: 1](x: T): T = x
stable: [T <: 1](x: T)T

scala> stable(1)
res0: 1 = 1

scala> stable(2)
<console>:9: error: inferred type arguments [2] do not conform to method stable's type parameter bounds [T <: 1]
              stable(2)
              ^
<console>:9: error: type mismatch;
 found   : Int(2)
 required: T
              stable(2)
                     ^

scala> def stable[T <: Singleton](x: T): T = x
stable: [T <: Singleton](x: T)T

scala> val x: Int = 2
x: Int = 2

scala> val y: x.type = x
y: x.type = 2

scala> stable(y)
res3: x.type = 2
[WIP] SIP-23: accept negated literal in infixTypeRest

e.g., val x : -1 => -1 = ???
WIP: quickfix for nopos in parser -- proper fix?
isSuitableLiteralType
widenIfNecessary