Enhance unsafe behavior with serverside validation facilitated via CLI

[jrschumacher]

We currently require the FQN in the backend (which are validated) for only delete of the object being deleted; update and reactivate do not require FQNs in the unsafe request. This confirmation flow seemed beneficial because the user wouldn't have to first print JSON in a separate command then copy and/or remember the FQN to type in the confirmation screen if we do a roundtrip in the client. We have some options.

1. We could add FQNs to update and reactivate and make them required fields to have the serverside validation for all unsafe requests. Then we could pass the user's interactive entry directly or retrieve it ourselves for --force.
2. We could do 1 and move every fqn entry to a flag --fqn then make confirmation a y/n like deactivation for consistency instead of typing in the FQN values interactively.
3. We could not do 1, leave FQNs off the update and reactivate requests, and do a y/n confirmation for them and an FQN interactive entry where the value is passed directly into the request (without verification clientside).

To me, it doesn't seem like doing an extra validation for UX is very likely get us in a troublesome loop as long as validation happens in the server for security/DX of the API.

Originally posted by @jakedoublev in #213 (comment)

[jrschumacher]

This is satisfied for the delete behavior which is the major concern. Currently, we have not been able to identify a way a defect in the CLI would induce an accidental deletion.