Enable some Jinja extensions and add datetime capabilities
Author: Rocketknight1
Pull request: yes

This PR enables a few built-in Jinja features, specifically the `loopcontrols` extension. This allows a few new features in templates, most notably the ability to `break` or `continue` in loops, which was previously impossible.

Also, this PR adds the ability to get the current date/time with a call to `strftime()`, since this was requested by the Llama team. A new `test_jinja_extensions` test is added to check that these features work as intended.

Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_32684). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

@amyeroberts good advice on the code - I moved it all out of the base tokenizer and into `chat_template_utils`, which cleans up the base tokenizer a lot. I think keeping `strftime_now` is a good idea, though, for three reasons:

1) It fulfills a need that will be very common (templates want to get the current date/time as a string for their system message)
2) stftime() is flexible enough for a lot of formats
3) We can't really expose more complex classes/libraries/datetime objects in Jinja to cater for all possible needs, only callable functions like this. As single functions go, this is a pretty useful/general one!

@amyeroberts Yeah, I understand! The problem is that the templates have to run in Python-jinja2, huggingface/jinja for JS, and Minijinja in Rust/TGI. This means I can't, for example, have composable functions that return `datetime` objects from the Python library, because those objects won't exist in the other languages!

That means I really do have to stick to functions that operate over simple types, and build for common use cases rather than universality. I think `strftime_now` is a decent compromise there. Also, we're not necessarily locked-in - if it turns out in future that we made a mistake, we can deprecate the function and search the Hub for templates using it and make automatic PRs to do it a different way.

> This means I can't, for example, have composable functions that return datetime objects from the Python library, because those objects won't exist in the other languages!

That's kind of my point! As we can't build a clean library of functions we should try to avoid adding functionality globally as it can't be well abstracted. 

> we can deprecate the function and search the Hub for templates using it and make automatic PRs to do it a different way.

Deprecation is hard and best avoided whenever possible. Searching on the hub is also no sufficient for catching everything -- people will have code running locally which we cannot automatically update. We've experiencing the pain of this in another situation with deprecation of some params in image processor configs, which we can never fully complete, so I'd rather we avoid this whenever possible 

This is fair - I'll try to keep it to a minimum! Still, something like `strftime_now()` is necessary for a lot of templates, just because "Current Date: 23 Aug 2024" or something like that is an increasingly common component of standard system messages.