Replace set_ui_content() with actual templating engine

[lentinj]

Currently Tour.js implements it's on sorta-templating engine in set_ui_content. It'd mean less code for us and be more future-proof if this was swapped out with a generic templating engine, e.g. mustache.

This also gives somewhere to manage what user-generated tours are capable of doing, by giving them a set of templates that are reasonably locked-down.

Alternatively, we could move the Tour-Templating process server-side and get rid of this entirely?

[lentinj]

We definitely go with server-side templating here.

[jrosindell]

This question was discussed at some length further with @hyanwong and @lentinj and we agreed with this decision to serve HTML and not JSON. This makes the translations easier among other things. We need to be careful with security to make sure tours can't inject nasty things on the page

[lentinj]

Okay, the above mega-commit reworks the entire Tour-rendering pipeline. The most interesting part is probably the converted tutorial: https://github.com/OneZoom/OZtree/blob/issue-537-templating-engine/views/tour/tutorial_MD.html - I'm pretty happy that the new format is an improvement and allows us to do more than we would otherwise. The major downside I've found so far is that you can't insert comments next to HTML attributes. But to be fair you couldn't do that in JSON either. You can bodge around this with "comment-x" attributes, e.g.:

https://github.com/OneZoom/OZtree/blob/5b6f79f3ec9c1656effa0d5a69ca48e111d1a92a/views/treeviewer/minlife_tour.html#L66-L71

I've tried to keep the configuration as-is as much as possible for now, so we can think about that in things like #539. This is the minimal plumbing to get Tour/TourStop to have settings it still recognises, and keep the site in a reasonably functional state.

This makes the translations easier among other things. We need to be careful with security to make sure tours can't inject nasty things on the page

Obviously if we let people write their own HTML it's game over, but for custom deployments that's a good thing. They can write their tour HTML, doing anything they like, and it can be exposed via. static/ to the tour engine.

For database-generated tours it's the same as any other user generated content; we escape in the template when inserting into the HTML, and on/off classes based on conditions. We will at some point have a default template for DB-generated tours, with slots for HTML, video, branding, etc. and translation for strings so any translation happens along with all other content.

[lentinj]

Merged into main with https://github.com/OneZoom/OZtree/pull/639