[WIP] Fixed #23753 -- Added a suite of SQL Functions

This is a work in progress, but not too far off being code complete. I thought it was better to open a PR rather than have people try to track individual commits on my fork.

A few notes at this point in time:

- ~~I plan on renaming Concat to ConcatPair (name TBD), and renaming ConcatMany to Concat.~~
- Some backends allow an arbitrary number of args to Concat, but I've chosen implementation simplicity by implementing multi-concat the same across all backends. If performance differences can be shown, I'll revisit this choice.
- ~~Some functions validate args in init, others in resolve expression. I think I'll standardise on init, since objects should be fairly complete on instantiation.~~
- I won't be implementing Case/When just yet. Michal on the ML has a better implementation than the one I had prototyped, and I'll let Michal finish and submit a PR for that part.
- ~~Tests are basic and should probably cover a lot more failure states.~~
- ~~Docs. They'll come last as always.~~

Are we happy about the namespacing? Is `models.functions.*` an OK place?
My idea of converters is that backend converters are applied to convert the data to uniform format, then the field converters change that format to the wanted Python object representation.

So, in this case, if the bug can't be fixed, then we need to add a backend converter. Doing that for Concat expression would be much better than doing it on all TextFields, but of course before we pass the expressions instead of internal_type to backend's get_db_converters that can't be done.

Maybe it is possible to add a cast on SQL level to Concat on MySQL, something like "CAST(Concat('foo', 'bar') AS CHAR)". It might be that if the datatype of Concat expression is incorrect on SQL level, then further operations on the value (say lower()) will not work correctly.