union contracts

Typed Racket should stop using or/c to represent union types, and should instead implement a true union contract combinator.

The main issue with or/c is that it raises an exception when two non-flat contracts in the or/c might apply to the given value. For example (or/c (-> boolean?) (-> integer?)) raises an exception when applied to any function with 0 arguments, because both contracts return true for contract-first-order-passes?.

Example (using TR commit 1560f17):

#lang racket/base

(module t typed/racket
  (provide f)
  (define (f (g : (U (-> Boolean) (-> Integer)))) : (U Boolean Integer)
    (g)))

(require 't)
(f void)
;f: contract violation
;  two of the clauses in the or/c might both match: (-> Integer) and (-> boolean?)
:  given: #<procedure:void>
:  in: the 1st argument of
;      (-> (or/c (-> Integer) (-> boolean?)) any)

Because of this limitation, or/c re-orders its arguments to check flat contracts first. This reordering causes a second issue --- it may affect Typed Racket's ability to optimize the contracts it generates.

(Thank you @rfindler for explaining why or/c might not be best for Typed Racket)

See also:
kt-icfp-2015.pdf

Start by reproducing the Typed Racket example in the issue and tracing how (U ...) currently becomes or/c, including the contract-first-order-passes? behavior. Done means a true union contract combinator handles overlapping non-flat contracts without raising an ambiguity exception and avoids unnecessary contract reordering.