Reduce Ceremony

## Describe the task

Presently relative simple features result in a large number of classes/lines. They are simple to understand lines but they are intimidating and annoying in PRs. We end up with about 25 out of 30 lines for a simple feature state being ceremony, or convention.

We have a number of these in our internal projects, this example is showing some message on screen based on an effect gathering and dispatching a string from other game context.
```csharp
//something somewhere does
dispatcher.Dispatch(new UpdateCategoryMessageCommand { Message = someDataSource.Get(desired).ValueOr(string.Empty) });

//declare the struct for the feature
public struct CategoryMessageState
{
public string Message;

public static CategoryMessageState Create()
{
return new CategoryMessageState()
{
Message = string.Empty
};
}
}

//declare it's reducers
public static class CategoryMessageReducers
{
public static void RegisterAll(FluxityInitializer initializer)
{
initializer.CreateReducer(Update);
}

private static CategoryMessageState Update(CategoryMessageState state, UpdateCategoryMessageCommand command)
{
state.Message = command.Message;
return state;
}
}

//definite the commands that result in changes
public class UpdateCategoryMessageCommand : ICommand
{
public string Message;
}

//define a simple presentation
public class CategoryMessagePresenter : Presenter
{
[SerializeField] private TMP_Text _text;

private IFeaturePresenterBinding _state;

public override void CreateBindings()
{
_state = Bind();
}

public override void Display()
{
_text.text = _state.CurrentState.Message;
}
}

//and for all of that to work at all, we presently have to do these in the appropriate places too
.RegisterFeature(CategoryMessageState.Create());
CategoryMessageReducers.RegisterAll(this);
```

## Area

Usability

## Additional context

Closely related to #39 and #34

Tension here comes from a few places:
- Reducers need to be static
- Feature data needs to be value type
- IFeature<>s are injected into things so need to exist early (before other parts of fluxity might like to configure themselves)
- Removing this as an expectation of the system and instead forcing the existing direct IFeature injects to go through the store, might make more sense

Potential steps to take:
- Remove IFeature as an injectable
- RegisterFluxity could take a (static) delegate so it can register all features in the store as it is made
- This would also allow the reducers to be made at the same time
- Introduce FeatureView to prevent need to Store.GetFeature everywhere
- Presenter then uses these instead of a bespoke code path
- Removes need to inject store in most things

Start by reviewing the current IFeature injection, RegisterFluxity setup, Store.GetFeature usage, and Presenter bindings described in the issue, alongside related issues #39 and #34. Define the agreed design before changing code; done should mean a documented, accepted way to register features, reducers, and presentation with substantially less ceremony.

由索引模型根據 Issue 內容生成。