Remove *mo blobs from source control

[n1ngu]

Compile them at build time with a hatchling custom hook (replacing poetry!)

Closes #505

[Endzel]

Any chance for this to progress @n1ngu ? This issue is happening in some of my deployments.

[n1ngu]

While removing and ignoring *.mo files and fixing strings in *.po files are the starting point to fix the actual issues, this should be followed by either

• Communicating a breaking change to installers, as they would now be required to run compile messages if they weren't already.
• Changing the build and release pipeline to compile messages before packaging this module. And also communicating this breaking change to third party builders.
• Merging this PR

But right now this is more of a proof-of-concept for a long-ago acknowledged bad practice in the Django ecosystem (see https://code.djangoproject.com/ticket/23321, https://forum.djangoproject.com/t/cease-and-desist-versioning-of-compiled-mo-files/23516). It works, but

• It is far from being a canonical solution, as you would require Django to build Django itself. Not an issue for community modules, but still hurts my head. I would not feel comfortable merging this upstream unless it used babel or raw gettext.
• It is very disruptive with the existing packaging solution (replacing poetry with hatch!).

So, I think there is little chance for this to progress unless the implementation is discussed with jazzmin maintainers. I am eager to have this discussion but in the meanwhile I am not pushing for this at all.

[n1ngu]

To be clear, I am uncomfortable with the build dependency introduced by this instruction. The only reason to do this was validating the workflow. But if community is ok with removing *.mo files and compiling them at wheel build time and replacing poetry with hatch, I'll invest some effort to rewrite this with babel or gettext.