Feature: Better experience for modifying RoleAssignments

[bmwinstead]

When RoleAssignments are modified, ASO can naively just try to update the existing RoleAssignment object. This results in an error - RoleAssignmentUpdateNotPermitted: Tenant ID, application ID, principal ID, and scope are not allowed to be updated.
This means that externally we have to be responsible for knowing when to, and deleting/recreating the RoleAssignment. It would be cool if ASO either:

1. Made the fields you can't change immutable in Kubernetes so you can't get into this state.
2. (preferred, maybe flagged?) Understood when the user was modifying an immutable field and triggered a deletion and re-creation of the underlying RoleAssignment object for you.

[theunrepentantgeek]

This is a good idea - building on the design of ASO as a goal seeking system.

I'll schedule the design work for this for our next release; once that's done, we can look at where it fits in our backlog.

[theunrepentantgeek]

We need to sort out write-once properties #1443
Some design work is required.