Darn liquid template tags...

Found another one...

Silly typo...

Allows editing in most modern editors according to the project defaults
without manual configuration.

Add cross-platform editor configuration

This commit is intended to address issues #175, #176, and #177.  It is a
fairly involved reworking of these templates that standardizes the
layout and, I hope, does a better job of rendering h-card information
for posts and so forth.

These changes introduce some structural changes to the HTML, including
consistently embedding webmention content in article tags, and
repositioning some of the relevant classes.

Any users of the default templates will want to inspect these changes
and make corresponding changes to their CSS.

Now, I have to admit, the sheer amount of code duplication across these
templates fills me with sadness, but because of the need to support both
client- and server-side template rendering, these things kinda need to
stand on their own.  I did explore the use of custom filters to render
blocks like the h-card using their own templates, but figuring out how
to make a custom filter on the JS side, not to mention testing it, was
beyond my ken.

This changeset is intended to address issue #172.  It introduces a new
html_proofer_ignore setting which can take the values "templates" or
"all".  When set to "templates", the behaviour is equivalent to setting
the html_proofer setting to true.  When set to "all", in addition to
that original behaviour, the included webmention templates will add the
data-proofer-ignore attribute to the rendered webmention output, which
will cause any content sent via webmention to be ignored by the proofer.

Yup, haven't made a mistake like this in years.  Maybe Pascal had it
right to make assignment a special operator...

This commit addresses issue #178 by adding an additional check during
the URI gathering phase such that, after the initial regex match finds a
URI, we attempt to parse that URI.  If that fails, we ignore the URI as
a spurious match and move on.

This is, of course, a hack.  In practice we should clean up that regex
so that bad matches don't happen.  But, since I don't know enough about
the history of that regex, and because that could turn into a game of
whack-a-mole, I went this route.  And, ultimately, this is just more
bullet-proof.

Note, these events are silently ignored at the regular logging level.
However, at debug level, a log message is emitted indicating a URI was
skipped.

This commit fixes issue #179. The method `set_data` sets the class
instance variable @DaTa with essential state information needed during
the render call.

However, as this tag is instantiated during the creation of a template,
its instance persists if the template is rendered multiple times. So if
a page is rendered with this template, and that page contains
webmentions, and then a subsequent page is rendered that has no
webmentions, if that state isn't cleared out, then it's erroneously used
in that subsequent call.

Well, prior to this changeset, the `set_data` method was only called if
webmentions were available for a given page. That meant pages without
any webmentions failed to clear the previously cached state, and the
webmentions would end up re-rendered in the current page.

This changeset modifies this method (and cleans up the ordering of the
code a bit) so that the state is always populated, regardless of the
presence of webmentions on the page. This ensures the @DaTa variable
always contains the state for the current page being rendered, even if
that state includes an empty list of webmentions.