Edition form performance - Part 2

This completes work for https://www.agileplannerapp.com/boards/173808/cards/5697 that was started with #1712.

The central premise is that we now cache data containers for taggable things that are used on the edition forms. We also cache the generated select tag HTML where possible (i.e. when none of the options are selected). The cached data is keyed using a digest that should change whenever any of the source data changes. Thus there is no need to explicitly invalidate any of the cached data. In local benchmark tests run against a recent database dump, the difference between before and after these optimisations are as follows:

edit case study form: 3.31s to 0.95s
new case study form: 2.64s to 0.81

edit consultation form: 3.25s to 1.05s
new consultation form: 2.80s to 0.85s

edit detailed guide form: 4.94s to 1.00s
new detailed guide form: 4.39s to 0.87s

edit news article form: 3.39s to 0.90s
new news article form: 2.96s to 0.89s

edit policy form: 2.77s to 1.01s
new policy form: 2.45s to 0.68

edit publication form: 3.18s to 0.86s
new publication form: 3.10s to 0.91s

edit speech form: 4.68s to 1.05s
new speech form: 4.57s to 0.81s

edit supporting page form: 1.35s to 0.743s
new supporting page form: 1.31s to 0.60s

edit world location news form: 1.34s to 0.77s
new world location news form: 1.34s to 0.63s

edit worldwide priority form: 1.94s to 0.97s
new worldwide priority form: 1.68s to 0.68s

So a minimum 50% improvement across the board. We'll have to wait and see how this translates to the actual production environment.

Assuming all is well with these changes, the same data containers could be used to improve the performance for other (non-edition) models in the app.