Require optional properties to be present in subtypes

This PR tightens subtyping rules such that optional properties are required to be present in subtypes.

We currently allow subtypes to drop optional properties. This leads to some odd effects:
```typescript
interface A { x: number; y?: number; }
interface B { x: number; z?: number; }
var a: A;
var b: B;
var c: [a, b];
```
This currently infers *either* type `A[]` *or* type `B[]` for `c` in an indeterminate manner. The reason for this behavior dates back to before we had union types--we wanted the above code to produce something better than `{}[]` so we engineered the subtyping rules to let this case by. And certainly picking `A[]` or `B[]` is better than picking `{}[]`. But it's pretty clear by inspection that A and B are different types and that neither should be a *subtype* of the other, even if they are both *assignable* to each other.

Union types enable us to do the right thing and give `c` type `(A|B)[]`. But we need to change the subtyping rules such that A and B aren't both subtypes of each other (because when they are, a union type is reduced to just one of them). With the suggested change a subtype is no longer allowed to drop an optional property. Specifically, if a supertype T has an optional property P, then a subtype S must also have an optional or non-optional property P. For the example above this means that neither A nor B is a subtype of the other, so the type of `c` becomes `(A|B)[]` which makes a lot more sense.

I'm also changing the [relational operators](https://github.com/Microsoft/TypeScript/blob/master/doc/spec.md#4.15.3) to require one operand be *assignable* to the other rather than one operand be a *subtype* of the other. This is pretty much the only place we use a subtype check with operators and it seems unnecessarily strict. In fact, the only remaining features that use subtype checks are union types and best common supertype checks in type argument inference and function return type inference. (Ok, the `instanceof` operator also checks that the right operand is a subtype of `Function`, but that's pretty immaterial.)

The change appears to have very little effect on real world code (one project, Monaco, required a few minor changes).

One change was required in the compiler itself, in a function in emitter.ts. That particular change is required because two anonymous types with properties of types that contain optional properties (subtle!) are no longer subtypes of each other. This actually shows the flip side of disallowing union types to be created for results of functions with multiple return statements--that would have been the right thing to do here. I'm still wondering if we really want to keep that rule (as opposed to just creating union types and relying on those to indicate what the problem was in case it wasn't intended).