resource lifecycle state

[matt-beanland]

Various resource states should be implemented when instance type == :resource
The service state is not relevant for resources.

Ash_state_machine can only go one one field per resource

resource lifecycle state is probably what we want to model: Planning, Installing, Operating, Retiring - there is no state machine as such, in that all transitions are possible.

[matt-beanland]

the assigner should only assign in Operating state, but should allow unassignment (in any state).
nil is allowed and will suppress the "lifecycleState" field in Jason.

[matt-beanland]

Adds TMF lifecycleState to resource instances. Service instances are unaffected — the attribute defaults to nil and is omitted from JSON when absent.

resource_state is a plain :atom attribute on BaseInstance with allowed values :planning, :installing, :operating, :retiring. No state machine is used — all transitions are valid, so a single lifecycle update action accepts any state directly, guarded by validate attribute_equals(:type, :resource).

In the TMF JSON output, lifecycleState appears as a top-level key positioned after the specification block, emitted only when the value is not nil via the existing Instance.Util.states/2 customisation path.

The assigner now enforces the lifecycle contract: Assigner.assign/3 returns an error if the source instance is a resource and its resource_state is not :operating. This is the prerequisite for the planned assignment DSL injection in behaviour do, which will make this guard declarative rather than embedded in the Assigner.

Code interface lifecycle_resource/2 added to Diffo.Provider. Test suite: 648 tests, 0 failures.