This should make tools using the library more robust; it’s slightly less
noticeable than a crash, but I’m not too worried about tool developers
missing the warning (both Flask and pytest show warnings by default).

The stacklevel=4 is a bit hacky and might break if Jinja2 changes the
number of stack levels in the template rendering code, but at the moment
it seems to work well with the magic that Jinja2 (or Flask?) does to
massage the stack trace and insert template lines into it – a template
with a {{ message() }} call for an unknown key is properly reported in
the warning:

> /home/lucas/git/lexeme-forms/templates/index.html:39:
> UnknownMessageWarning: Message 'unknown' not found in ['en']

And Python code directly calling message() also works nicely:

> /home/lucas/git/lexeme-forms/app.py:280:
> UnknownMessageWarning: Message 'unknown2' not found in ['en']
>   message('unknown2')

But I consider this a nice-to-have, and if it breaks it might be best to
just set stacklevel=1 rather than try to work around it with more
elaborate hacks like message() / _message() here: usually the message
key itself should be enough information for developers to identify the
buggy call.

I’m not sure if including the language codes in the warning message is
actually useful (recall that we have checks asserting that other
languages don’t define any message keys which aren’t found in English,
and English is hard-coded as the final fallback, so the warning can only
happen for message keys that aren’t defined in English, and all other
languages in the fallback chain are basically irrelevant), but for now
let’s keep them there. We also export UnknownMessageWarning – I don’t
expect it to be useful to most tools, but it seems mean to *not* export
it in case someone wants to filter out the warning for whatever reason.