Represent capabilities as sealed interface hierarchies

Represent capabilities as sealed interface hierarchies

Summary:
Up-casting of capabilities gives up privilege and is safe.
Contexts are represented by lowercase names and there is a 1-to-1 mapping to same-named composite capabilities. Capabilities are organized into sealed interface hierarchies.

**Note**: These are all sealed types in `HH` namespace, so users won't be able to mess up with them, only the typechecker will.

The new syntax for contexts will support specifying any context from `\HH\Contexts`. For a function annotated with a context `ctx`,

- the required capabilities to call are determined by `\HH\Contexts\ctx`
- the provided ones (but not required), which is unsafe for effect tracking, determined by `\HH\Contexts\Unsafe\ctx`

This capability-based **coeffect system** is analogous to
the [coeffect system](http://tomasp.net/coeffects/) of Scala's **implicit parameters**:

- the former (required & provided) would be *required* implicit arguments (without a default value)
- the latter (provided only) would be additional implicit parameter(s) whose *default value* is an *unsafe* capability (i.e., not required by callers), or as *locally* introduced implicits to the function body

The latter is unsafe because it introduces a privilege by creating a capability, as opposed to requiring it from the caller / initial entry point. Therefore, these additional mappings from contexts to such capabilities are put inside the `\HH\Contexts\Unsafe` namespace
(they must have the same name, to simplify the desugaring of the new context syntax).

Multiple capabilities are represented using intersection types,
where mixed is a no-op (i.e., doesn't add any privilege).

Reviewed By: zilberstein

Differential Revision: D22677240

fbshipit-source-id: cb49b5aa6568780d941ced4cfdb074367de24bdb