Bootstrap 5 support

[guruofgentoo]

Bootstrap 5 has been around for a couple years, so it's high time we support it. I do have this "done" at an app level in one project, but promoting to the lib level is going to be a little tricky. Some things to think through:

• Bootstrap 4 will continue to be used in some projects. We should add a KEG_BOOTSTRAP_MAJOR_VERSION config option, and switch on that when needed
• The form macro changes I made at the app level will cover #183, so we can just fix that for BS5 and leave BS4 as-is
• Bootstrap no longer depends on jQuery, and IMO we should work to take jQuery out of our apps at this point
  • We still use Select2 for form dropdowns. It is feature-flagged in via KEG_USE_SELECT2
  • I'd rather switch to TomSelect, use it with a separate feature flag, and adjust the select2 use to take the bootstrap version into account
• Jinja block names have gotten a bit convoluted
  • In the beginning, we used flask-bootstrap. That lib had opinionated block names in its base template, so we have historically used styles and scripts blocks
  • Then came bootstrap-flask, which was less opinionated in that we had to use our own base template
  • Then https://github.com/level12/keg-app-cookiecutter/commit/c1dfe19350bf8946c06d40153f529648f1096b3f happened, breaking library-level script blocks on new projects.
  • The upside of having consistently-named blocks within the base template is obvious - they are all under body and are named accordingly
  • Unfortunately, keg-elements assumed otherwise, so select2, custom form JS, etc. didn't work out of the box
  • Also, jinja doesn't give us the option of using variable names for blocks...
  • Options to resolve
  • This could be as simple as standardizing the lib on body_scripts and require apps to follow suit
    • That feels like the wrong approach. Apps shouldn't be dictating internal library code
  • We could standardize on keg_styles and keg_scripts, and require apps to put those blocks in an appropriate place in the base template
    • I like this approach better, as the libs already dictate some details of implementation
    • I can envision order-of-inclusion issues, but that's a solvable issue IMO
• Worth thinking about whether the library is too tied to Bootstrap
  • I'm considering moving any templates that are Bootstrap-specific to a namespacing folder, and then adding a KEG_TEMPLATE_FLAVOR config option (defaults to bootstrap)
  • I believe jinja allows for variable use in include paths, so framework-agnostic generic templates could include the framework-specific version

[guruofgentoo]

With the above commit, there are just a couple of BC-breaking updates to make in each app after updating kegelements and keg-auth:

• (required) set KEG_BOOTSTRAP_MAJOR_VERSION config to 4
• (optional) change templates 'horizontal-b4.html' references to 'horizontal.html'
  • No-op change, but switches from the hardcoded Bootstrap version to the one configured