[Feature Request - Defined State Management] Remove requirement for hardcoded (error prone) status options

### Problem description

As a policy creator, I need to keep track of different states for each individual button. Throughout the creation of a policy, this is cumbersome as I need to know whether something could be "Approved", "Rejected", or something else, this _is free text_.

As a demand provider, I need to ingest different status/state options over or different policies and been able to map different options or states from 'n' options to a comparable/truthy value.

The issue compounds whereby different policy providers have different formats of states that inevitably lead to the same outcome.

#### Example.

An **approval** States for a given button may have these different options over all policies in the guardian ecosystem.

- Approved
- approved
- APPROVED
- yes
- Yes
- YES
- Or any other positive connotation

For all demand aggregators or other like services. There is an expectation that you need to be able to understand at a language-level which positive outcome or negative outcome maps to different states.

If we consider the normal flow of and authority, either needing to approve, project, or ask for more information there is only a finite number of states, we should realistically provide to the user.

## What would be beneficial?

The ability to define states and to link it to a type, perhaps been able to link a button or UI to a set of states. There should be warnings for modifying, a state label or title within the UI, whereby it makes it harder for an asset to be identified. In addition, the validation check should ensure that the correct states have been selected for button objects or other like-UI, to reduce the time and frustration hardcoding different states.

In short, standardising all state options for all policies -- perhaps having a new type of button that is linked to a custom state list/enum sat with drop-down links could be the way to go.

The states could be anything, but the goal would be to be standardised throughout all policies:

- approved
- rejected
- etc

While this is good for the demand side of value extraction. This is highly beneficial for the creator of policies as you could select the correct value from a state-list drop down instead of having to hardcode all state options for button, selection or filters for approved or rejected states.

## Notes

Genuinely, I believe that solving these kind of problems, whereby you can set of values ahead of time, and less onus on Freeform text within the policy itself would be highly beneficial to all participants using the Guardian. There has been comments on the Guardian, being fragile or brittle and this kind of solution would go along way to solve these UX/DX problems - ultimately, ending up being more of a finite-state machine and moving towards being more immutable and less error prone.