Transition away from Handlebars for style guide templates?

We've discussed adding support for other templating languages for patterns (#22), but this issue is specifically about what we're using for this project's layouts, templates, etc.

I've noticed over the course of some recent projects and making modifications to this one that Handlebars has a number of shortcomings:

- It doesn't support async helpers or functions. More and more libraries are writing asynchronous features by default these days, so that limits what helpers we can expose to the style guide.
- It doesn't support relative paths in includes.
- It doesn't have a unique filter syntax, resulting in messy `{{nested (shortcodes (of (doom)))}}`
- It doesn't support conditionals that are more complex than truthy/falsy checks.
- Its loop syntax can be confusing since it assigns the current value to `.` or `@this` (whereas most other template engines cast the current element to a property name like JavaScript does).
- While it supports extensible blocks in partials (@gerardo-rodriguez wrote [a great article on this](https://cloudfour.com/thinks/the-hidden-power-of-handlebars-partials/)), its syntax for doing so is not very discoverable.
- It is not fully supported in certain Eleventy Frontmatter properties (such as pagination).

Looking at [Eleventy's built-in template languages](https://www.11ty.dev/docs/languages/), I can't help but gaze enviously at [the list of supported Nunjucks features](https://www.11ty.dev/docs/languages/nunjucks/#supported-features)… 👀

Especially interested in @Paul-Hebert's opinion as the originator of this repo!