let-aliasing + removing let imps

First draft of proposal to remove implications from the let typing judgment (replaced by a logically equivalent or) and add aliasing for let-bindings where the expression being bound has an object (e.g. x, (car y), etc...).

This speeds up type checking (e.g. the 'filters-more' function from http://bugs.racket-lang.org/query/?cmd=view&pr=14838) and adds the ability to typecheck expressions that utilize simple let bindings of pure expressions, such as the following function:

#lang typed/racket

(: foo (Any -> Number))
(define (foo x)
  (match x
    [(? number?) x]))


The current implementation has 2 errors when running the unit tests at the moment, which relate to usages of types with '...' such as:

(let: ((f : (All (b ...) (Any ... b -> Any)) (lambda x (quote x)))) (lambda xs (apply f (quote y) xs)))

Obviously I need to work out these errors before this is pulled, but this is what it looks like at the moment, FYI.

I don't think it's an issue. 

#lang typed/racket

(let ()
  (: f (->* () (#:k Number) Number))
  (define (f #:k [x 0]) x)
  (let* ([g f]
         [h g])
    (h #:k 2)))

This works.

I could be totally wrong, but here's how I see this at the moment:

The only identifiers which can alias objects are identifiers introduced in the binding pair of a let expression. It is when we begin typechecking a let expression that these binding id/expression pairs are are both typed and potentially aliased at the same time. When we see a variable in the wild, whatever kind of variable it is, we resolve any potential aliasing and _then_ look up type information through the normal channels. It's impossible for us to hide any type information with the current aliasing approach when compared to the normal typechecking approach -- we're still recording the same types in the environment like we used to *with the exception* of a slight redirection via aliasing in some cases. The normal logic built into looking up type info for any particular identifier is still always there, even if we went through an alias indirection to get to the variable we're looking up now.

I just don't see how this could be an issue. All info that was recorded in the type environment is still recorded in the same type environment, and type-lookups are unaffected by aliasing -- we just have to make sure during typechecking we resolve aliasing before we lookup a type (which we do).

I'm happy to be edified if I'm mistaken in there somewhere!