Integrate former experimental branch 'encapsulate-runtime'

[michaelschnyder]

I massively restructured the whole runtime with the following goals

• separate runtime funtionality from the forked execution part (i.e. don't call a Http Endpoint)
• removed shared state in runtime and split responsibilities to smaller components
• therefore, be able to write tests Create Tests for the Runtime itself #18
• and be able to add & test newer requirements without requiring real executables and processes

In addition to that, I suggest to rename the forked execution nuget package to Jobbr.Runtime.ForkedExecution and rename the specific runtime class to ForkedRuntime.

Additional toughs:

• The In-Process version would still be called "Jobbr.Server.Execution.InProcess" without the need of an additional package because the runtime will not be visible to the user there. Only the Core Runtime will be integrated by ILMerge.

• If we are going to implement a remote running agent, it could be named "Jobbr.Server.Execution.Remote" or something similar. The agent itself could be a light-jobserver, and reuse the existing registration logic and execution models, so that the remote agent either would re-use the InProcess or the ForkedExecution extension. An additional package might not be needed.

• An alternative option is to inverse the logic and use a similar approach like in the server. The runtime is the master, and adapters (for connecting to the fex endpoint), InProcess, Remote are registered in the runtime.

@olibanjoli I don't see any benefits when with the third variant and would like to continue as described.

[olibanjoli]

I also don't see any benefits. +1 continue as described

[michaelschnyder]

merged to develop and released on nuget, old runtime (console) unlisted