Provide access to the JCR user and workflow session as well as the subject (if available) of a Workflow instance through the WorkflowContext (protected)

Rationale:

For many custom Workflow implementations, and especially WorkflowEventWorkflow, additional repository context (content) is often, and more often, needed which cannot be practically be 'mapped' with or through a Document (JDO) model.
This is too limiting for needed extensions and customizations and the only current 'alternatives' are either too complex as well as more dangerous and/or plain undesirable workarounds:
a) fall back to using InternalWorkflow, which does expose these already, but isn't supposed to be used publicly
b) write a daemon service (just) to invoke it to expose a JCR session to the workflow implementation

Exposing the JCR user and workflow session is trivial to add though as well as the 'subject' node of the workflow instance.
This does open up the door for more direct and low level JCR interaction during the workflow invocation, but the alternatives (see above) do so as well.
So exposing these directly really only makes live much easier for the developers, and makes its more likely they will then use the much more lightweight and easier to implement WorkflowEventWorkflow.