Rework the IAMObject Abstract Asset to Extend Information

[andrewbwm]

Rework the IAMObject abstract asset to extend the Information asset and connect the attack steps that make sense.

• IAMObject Deny leads to Lockout.
• IAMObject Write leads to Assume.
• IAMObject Lockout leads to Deny on the Data is has ReadPrivileges for and on the Applications it has ExecutionPrivileges on. The other types of privileges Write and Delete on Data and High and Low on Applications were not seen as necessarily propagating the effects of a lockout. There may be circumstances where, for example, removing write privileges would impact the functionality of using the data. However, these are defined by the specific functionality of that Data asset and therefore beyond the scope of coreLang.
• Rework Privileges to serve as a subset for any IAMObject class, not just Identity and Group. This also allows the modeller to build Privileges hierarchies, I doubt it will be a commonly used feature, but it seemed like a more generic and cleaner design anyway.
• Lockout a whole Group if all of the member Identities have been locked out.

[andrewbwm]

* `Lockout` a whole `Group` if all of the member `Identities` have been locked out.

This is a debatable inclusion, I liked it enough to include it in the initial pull request, but let me know what you think of it, @skatsikeas. If you feel it is overly assumptive let me know and we can drop it.

One could make the case that since the group itself is not denied it should not be reflected on it, new users or users not modelled could exist that could still make use of those privileges. However, if we do decide to drop it we may have some funky situations where all of the users Idenitities are locked out, but since the relevant privileges are on the Group for whichever reason the lockout is not propagated.