Introduce ALC-based dependency isolation

[davidmrdavid]

This PR introduces the basic project skeleton of the new Durable Functions PowerShell SDK. In this solution, there are 2 projects:

• DurableEngine: which implements the Durable Functions logic. This is where most of the code will reisde.
• DurableSDK: which defines the user-facing APIs. Behind the scenes, these APIs will make calls into DurableEngine methods. This is meant to be a really lightweight "shim" project that re-exports DurableEngine logic.

The reason why we split this solution into 2 projects is to prevent dependency conflicts at runtime.

Why are we concerned about dependency conflicts If the PowerShell worker has a conflicting dependency version from this SDK (e.g incompatible versions of Newtonsoft.JSON), that may cause runtime errors. This has happened several times during development because this new SDK depends on the Durable Functions C#-isolated package, which carries complex dependencies that can change at any time. As a result, some dependency isolation is needed.

How do we deal with dependency conflicts in PowerShell According to this documentation, the most robust solution is to implement an Assembly Load Context (ACL) which adds a layer of indirection between dependencies that may cause runtime conflicts.

This PR implements ALC, as per the documentation, in the simplest way we could. Since ACL is an advanced concept, this PR is trying to avoid making any fancy changes, the code is almost exactly as found in the official PowerShell example linked above.

In doing so, we have divided the solution into the 2 aformentioned projects. The DurableEngine piece will import the C#-isolated SDK and use it to implement the logc powering the SDK. Meanwhile, the DurableSDK will simply re-export the DurableEngine logic, whose dependencies are isolated through ALC, to the user-code via CmdLets.

You should know: This PR introduces only our ACL implementation, which deserves its own dedicated review effort. A future PR will introduce the actual code that will reside inside the DurableSDK and the DurableEngine components. I considered that mixing ALC with any other features would have made this PR harder to review.

This ALC stuff seems dangerous, is this really worth pursuing? After this PR, which introduces ALC, the rest of the codebase should be fairly standard and a simplification of the DF PowerShell SDK we have today. I agree that messing with assembly loading can seem scary, but this implementation is mostly just a "copy-paste" from the official guidance, so I trust it should be robust.

[davidmrdavid]

FYI @michaelpeng36

[AnatoliB]

Wondering why everything is under samples/durableApp

[michaelpeng36]

@AnatoliB The source code was initially written directly under the samples/durableApp/Modules folder to facilitate testing with a Durable PowerShell application, but we can move the source code to be under src/ and modify the build script accordingly for test cases.

[davidmrdavid]

@daxian-dbw thank you for your feedback so far. I've responded to your requests and would appreciate another pass to make sure all looks good. Thanks!

[Francisco-Gamino]

@davidmrdavid -- I left a minor comment. Otherwise, LGTM.