Avoid using decl_class_type wherever possible

Avoid using decl_class_type wherever possible

Summary:
When `shallow_class_decl` is disabled, we must avoid lazily looking up shallow class declarations using `Shallow_classes_heap.get`. As of {D13570861}, this function throws an exception when `shallow_class_decl` is disabled, since without a shared-memory store of shallow classes, we have no guarantee that we aren't wasting time needlessly re-parsing the class we are trying to look up.

When `shallow_class_decl` is enabled, we must avoid computing `decl_class_type`s or `Typing_defs.class_type`s, since we would like to replace all uses of them with lazy lookup. Computing and storing the legacy class types will waste time and memory.

To deal with this, we represent classes in Typing_classes_heap with a new type, `class_type_variant`:

```
type class_type_variant =
  | Lazy of lazy_class_type
  | Eager of class_type
```

When `shallow_class_decl` is enabled, we only ever construct the `Lazy` variant. When it is disabled, we only ever construct the `Eager` variant.

Wherever we currently use `decl_class_type` directly (for example, in `Ppl_check`), we replace those uses with `Typing_classes_heap.t`, so that when shallow class decl is enabled, we will lazily look up the information instead of relying on the eager-class-decl store being populated.

Previously, the `dc_ppl` field was not propagated to `Typing_defs.class_type` because the `Ppl_check` module used it on `decl_class_type` directly. Since we are now using `Typing_classes_heap.t` to abstract over whether `shallow_class_decl` is enabled, it's necessary to propagate this field to the typing `class_type`, and we add the field `tc_ppl` and the accessor `Typing_classes_heap.ppl`.

Reviewed By: pittsw

Differential Revision: D14876508

fbshipit-source-id: 2a3b3a0f1d0649e51da7aa83408b02a2035f7d18