contrib.messages refactor/roadmap

### Code of Conduct

- [x] I agree to follow Django's Code of Conduct

### Feature Description

While working on an old messages framework ticket (https://code.djangoproject.com/ticket/13376) I have explored the messages framework in a fair amount of detail. I would like to do some refactoring and improvements to this package to make it easier to maintain and extend in future.

### Problem

While doing this ticket I noted 2 main problems:

* Some of internals are confusingly arranged and so some imports in the storages don't make the most sense.
* To fully complete the above ticket, I feel there is a better API design that could allow for easier and deeper customisation for those that want it and likely open up new possibilities for this part of Django.

### Request or proposal

proposal

### Additional Details

I'm happy for this to be slow and steady in terms of how we roll this out over several releases. This feature is more outlining my current thoughts/ideas to get by in.

I raise this now as I note there is a new ticket about adding a clearing message function which would play into this work in some manner.

### Implementation Suggestions

## Imports

* The cookie storage file has JSON encoder/decoders used not just by the cookie storage but by sessions.py as well. In them is nothing specific to the cookie storage, they are more about encoding the Message class in base.py, so they would be better placed to be either moved to base.py or a new file.
* The Message class could also be moved into a new file with the Encoders/Decoders (possibly)

## Improved API

This API work would be somewhat exploratory in nature, but the general idea is to provide a richer API for customising both the Message class and Storage classes without the need to override the core functionality (e.g. `__iter__` on BaseStorage). I'm thinking along similar lines of Class Based View methods without the deep inheritance structure.

The Message class is a useful python encapsulation of a Message in the messages framework, and would be an ideal thing to subclass to further customise the message itself to store extra data of customise how data is stored/retrieved in concert with a custom storage class.

However right now the base storage class hard-codes the interaction with the Message class. My proposal would be to refactor the BaseStorage class to allow the Message class to be substituted for a custom Message class as well as refactor the methods to operate on the Message class more directly rather than just the `add` method which the only current place it is used.

Finally we could possibly combine the current JSON Encoder/Decoders into Message class itself rather than have separate classes.