Add client time to server start time.

Summary: Ideally, `Unix.time () - start_time` would measure the total time it takes to start the
server from the moment the user issues a `hh_client start` command. Previously,
we ignored the time spent in running `hh_client` since that was generally negligible.
However, now that `hh_client` can invoke an external options script, the running time
can actually be noticeable depending on what the external script does; hence, we
should really set `start_time` when `hh_client` starts up, rather than when `hh_server`
gets started.

Reviewed By: @jwatzman

Differential Revision: D1737767

Signature: t1:1737767:1418429942:109e016d9eb54b561f040703355343fb73f42b8f
Fixes for vasm-llvm backend.

Summary: Down to 12 failures in test/quick. At least 1 test is flaky and sometimes
it goes to 11.

- Allocate data sections close to code to ensure 32-bit relocations point
  to correct code locations. This also fixes assertions we get with
  debug LLVM builds.
- Update LLVM with fixes to stack alignment in HHVM_TC calling convention
  and disable 8-byte stack alignment override.
- Enable smashable calls.

Reviewed By: @swtaarrs

Differential Revision: D1736576

Signature: t1:1736576:1418411702:b527abd17f6b8091561c7e7fb33015941bd10749
Support rVmFp modifications in llvm backend

Summary: I considered giving it the same treatment I gave rVmSp in D1622952 but
that would've required making changes to hundreds of hhir opcodes to add an
explicit FramePtr src. This ended up being fairly simple and should work just
as well.

Reviewed By: @maksfb

Differential Revision: D1735985
Support static/self::TypeConst access

Summary: One thing that will make Type Const a compelling feature is the ability to access them via "self" and "static" access. For the most part the semantics of "self" and "static" in a type access hint is the same as self and static in expressions accessing constants.

For "self" we are able to resolve during naming, so we replace all references before reaching the typing phase.

For "static" it is a bit more nuanced. When expanding a type access we have to keep track of what the current class we are examining. For example

```
class A {
  type TC = int;
  type TC_static = static::TC;
}

class B {
  type Foo = A;
  type Bar = static::Foo;
}
```

Then when trying to resolve B::Bar::TC_static we do the following:

```
type = B::Bar::TC_static, root = B, tconst = Bar, rest = TC_static, static = ""
type = (static::Foo)::TC_static, root = static, tconst = Foo, rest = [], static = "B"
type = (B::Foo)::TC_static, root = B, tconst = Foo, rest = [], static = "B"
type = A::TC_static, root = A, tconst = TC_static, static = "B"
type = static::TC, root = static, tconst = TC, static = "A"
type = A::TC, root = A, tconst = TC, static = "A"
type = int
```

From the above example it should be clear that "static" refers to the previous root (after resolving "static"). The other thing to note is we have to expand through type defs. This is due to the fact we use type defs as part of the representation of these.

Reviewed By: @jwatzman

Differential Revision: D1732621