Unsafe user actions rework

[andrewbwm]

This is a bit of an everything and the kitchen sink pull request.

Broadly, these commits deal with how we model unsafe activity performed by the user.

1. Separate unsafe user action into two components. One that requires the attacker to be reachable from the Application and is more potent. The other does not require reverse reachability but is therefore more complex and requires substantially more effort.
2. Have unsafe user activity on a system fulfil the physical access requirement of vulnerabilities
3. Create a separate attack step on Data called Extract that represent the ability of the attacker to obtain the data and associated information as opposed to a regular Read which can represent autonomous tools/code reading the data and using it for further attacks.
4. Simplify ConnectionRule attack steps. The goal is to have the ConnectionRule asset mostly behave as a virtual asset that specifies connectivity and direction, but not trigger attack steps itself.
5. Introduce SendData and ReceiveData associations between Data and Application assets. Before Data were represented only as DataInTransit on Application assets and the direction was to be determined from the ConnectionRule assets. This was cumbersome so now Data are DataInTransit over Network assets and sent or received on Application assets.
6. Simplify unsafe user action by removing the high/low privileges distinction(this is now already covered by the fact that social engineering leads to Assume on the Identity assets associated with the User asset) and removing the forced/unforced dichotomy as well. All unsafe user action is now a result of Attacker actions, which prevents situations where no attack graph from the attacker could be generated. The unforced component was not adding any modelling depth and was therefore entirely removed.

We may wish to evaluate how unsafe user activity on System assets should be modelled as well.