Add support for dotnet-isolated runtime.

[viktorvan]

This PR closes #596

The changes in this PR are as follows:

• Add RuntimeKind for DotNet runtime for Azure Functions to enable running as dotnet-isolated.

I have read the contributing guidelines and have completed the following:

• Tested my code end-to-end against a live Azure subscription.
• Updated the documentation in the docs folder for the affected changes.
• Written unit tests against the modified code that I have made.
• Updated the release notes with a new entry for this PR.
• Checked the coding standards outlined in the contributions guide and ensured my code adheres to them.

If I haven't completed any of the tasks above, I include the reasons why here:
No docs updated, the runtime options are not currently listed in the docs.

[viktorvan]

The default runtime, when no runtime is explicitly set is still "dotnet". In the future maybe it will make sense to make "dotnet-isolated" the default.

[ninjarobot]

I recommend just adding the DotNetIsolated case to keep the use_runtime call simple.

[ninjarobot]

Rather than introducing the RuntimeKind type that is only specific to the DotNet case, it would be easier to use if DotNetIsolated is just another case altogether that represents the "dotnet-isolated" option. Then the usage remains simple like

use_runtime DotNet

or

use_runtime DotNetIsolated

[viktorvan]

Yes, that's a good point, use_runtime DotNetIsolated feels better than use_runtime (DotNet Isolated).

Since the RuntimeKind was an idea from @isaacabraham maybe he wants to weigh in as well? Should we just go with a DotNetIsolated case?

[ninjarobot]

Yes, I am thinking from the perspective of use_runtime in the DSL, but I would definitely like to get perspective from @isaacabraham as well.

[ninjarobot]

@isaacabraham can you please comment on this as to whether or not to break out the RuntimeKind for these?

[isaacabraham]

Yes, I think merging them will be better from a public API consumption point of view.