Do not use Provider_context.entry in bulk decl service checks

Do not use Provider_context.entry in bulk decl service checks

Summary:
Checks performed by `hh_server` don't use `Provider_contex.entries` machinery, while the ones in `hh_scheduler` do. This turns out to be major source of slowdown, caused by entries trying to handle cases of locally modified IDE files, instead of immediately defaulting to cached naming table information. In particular, [this code in naming_provider](https://www.internalfb.com/code/fbsource/[d91fc6294f6bd5438677c4de2b53cfa9a466df0c]/fbcode/hphp/hack/src/providers/naming_provider.ml?lines=54-64%2F) performs very poorly if our entry is a file with thousands of classes.

We could keep optimizing entries cache to better handle those cases, but I don't think it's worth it now - it seems safer to keep them only to what they were designed for (IDE scenarios), while for the massive parallel checks we should minimize divergences from what `hh_server` does.

This diff achieves that by switching `hh_scheduler` from `Tast_provider` to `Typing_check_job`. I wanted to directly call into `Typing_check_service.process_file`, but that would bring entire `hh_server` dependency into `hh_scheduler`, so there is some code duplication.

Differential Revision: D29472328

fbshipit-source-id: 19c527930385f629a32ce21d87ff05f06bb665f7