Use a state machine to model Watcher objects lifecycle

Description
----------------

Following https://review.openstack.org/#/c/266461/, we now have a fully detailed documentation on the state machine of both the audit and the action plan.
The problem is that this documentation is only detailing the expected life-cycle these objects. Indeed, very little to no validation is made whenever trying to perform a state transition.

What we would need is:
- A way to model all the possible state transitions an object may be subject
- Be able to express pre-conditions and/or permissions before being able to perform a state transition

Concrete scenarios outlining the need (should apply to audits and action plans)
------------------------------------------------------------------------------------------------------------

(1)
GIVEN that I am an administrator
AND I previously generated an action plan
AND this action plan is in the RECOMMENDED state
WHEN I try to trigger this action plan using the API (by patching its state to TRIGGERED)
THEN the API should accept my request (because the state transition exists and we are allowed to do it through the API)

(2)
GIVEN that I am an administrator
AND I previously generated an action plan
AND this action plan is in the SUCCEEDED state
WHEN I try to trigger this action plan using the API (by patching its state to TRIGGERED)
THEN the API should reject my request (because the state transition does not exist)

(3)
GIVEN that I am an administrator
AND I previously generated an action plan
AND this action plan is in the ONGOING state
WHEN I try to mark this action as failed plan using the API (by patching its state to FAILED)
THEN the API should reject my request (The state transition does exist but we are not allowed to do it through the API)