Enable unit testing of the DF API

[davidmrdavid]

Related to: #257

This PR is a first step to facilitating and encouraging unit testing of DF orchestration functions by end-users.

To achieve this, this PR does 2 things:
(1) It removes a layer of indirection in the DF API. Previously, the DF APIs were all defined in the Orchestrator class and dynamically assigned to the OrchestratorContext object at runtime. This made it confusing to mock DF APIs because, while user-code calls APIs on the context object, the user would have to mock the methods defined in the orchestrator class instead.

Now all DF APIs are inlined in the context object itself.

(2) Export a "dummy" orchestrator objects for users to use as a mock/stubbing target. In order to test an orchestrator function, users have to provide it with a context argument, which isn't easy to construct due to framework-internal idiosyncrasies. Now we export an implementation of the context interface that's been prepopulated with dummy values and that can flow through the orchestrator's handle method without exceptions. End users are expected to then mock this object's API endpoints and test their orchestrators through it.

As an aside, this API also happens to update our reference to @azure/functions type declarations, which required a tweak in some of our internal tests. Our .vscode files have also been pretty-fied and slightly updated.

[davidmrdavid]

After this PR is merged, remaining action items include:
(1) providing more comprehensive testing samples
(2) adding a reference to this to the official durable docs

[ConnorMcMahon]

Looks good, but a few logistics questions.

[ConnorMcMahon]

Is this port specific to your own local configuration for functions CLI, or can it be any open port?

[davidmrdavid]

I believe this can be any open port. However, I didn't manually specify this file so I can't say with certainty, it was autogenerated when setting up my debugging experience, so I suspect the chosen port is the default for these kinds of operations :)