I ran into this as a knock-on effect from having misspelled a section
name identifier (i.e. I had a \k{nonexistent-name} in my document).
Before I fix the document, I should fix the segfault!

Naturally, after calling the previous commit '1.2', someone had to
instantly find a bug that shows up in the simplest possible example
Halibut invocation :-(

I became aware a few months ago that enough is known about CHM files
that free software _can_ write them without benefit of the MS HTML
Help compiler - in particular there's a thing called 'chmcmd' in the
Free Pascal Compiler software distribution which is more or less a
drop-in replacement for hhc.exe itself.

But although depending on chmcmd would be a bit nicer than depending
on hhc.exe, Halibut has always preferred to do the whole job itself if
it can. So here's my own from-scratch code to generate CHM directly
from Halibut source.

The new output mode is presented as a completely separate top-level
thing independent of HTML mode. Of course, in reality, the two back
ends share all of the HTML-generation code, differing only in a few
configuration defaults and the minor detail of what will be _done_
with each chunk of HTML as it's generated (this is what the recent
refactoring in b3db1cce3 was in aid of). But even so, the output modes
are properly independent from a user-visible-behaviour perspective:
they use parallel sets of config directives rather than sharing the
same ones (you can set \cfg{html-foo} and \cfg{chm-foo} independently,
for a great many values of 'foo'), and you can run either or neither
or both as you choose in a given run of Halibut.

The old HTML Help support, in the form of some config directives for
HTML mode to output the auxiliary files needed by hhc.exe, is still
around and should still work the same as it always did. I have no real
intention of removing it, partly for the reasons stated in the manual
(someone might find it useful to have Halibut generate the .HHP file
once and then make manual adjustments to it, so that they can change
styling options that the direct CHM output doesn't permit), and mostly
because it wouldn't save a great deal of code or complexity in any
case - the big two of the three auxiliary files (the HHC and HHK) have
to be generated _anyway_ to go inside the .CHM, so all the code would
have to stay around regardless.

No functional change, but this opens the way to have further sets of
config directives that parallel the \cfg{html-foo} family but with
different prefixes in place of 'html'. The previous code to treat
prefixes 'html' and 'xhtml' the same was not general enough because it
depended on the coincidence that the former is a suffix of the latter.

I introduced this in commit b3db1cce3, which I hadn't really meant to
push at all yet (it's groundwork for a new feature that's still in
development), but which I had absentmindedly left lying around in my
usual checkout directory when the time came to do 84ed4f994, and which
got pushed as a side effect without having been quite fully tested
yet. Ahem.

I had no idea that was a thing HTML Help could do at all, let alone
that .chm files could enable or disable it via a flag! But Tino
Reichardt sent in a patch which sets one extra bit in a flags word in
the .hhp file, and despite 'chmspec' not mentioning that bit at all,
it does indeed seem to do something useful.

Turns out we can get a null pointer passed through from the front end,
if the input file was erroneous in some way, so we should do fallback
processing if so (exactly what doesn't matter much) rather than crash.

Patch due to J. Lewis Muir, who points out that the HTML backend's
current policy of _always_ disabling the TOC in single-file mode is
excessively harsh: in a long or formal enough document, you might
still want a TOC to make navigating around within the file easier,
even if it's not necessary to use it to get between multiple files.

So this change removes the unconditional prohibition against TOCs in
single-file documents, but they're still disabled by default, because
a single file counts as a leaf file and the existing default settings
disable TOCs in leaf files anyway. So if you do want a TOC in a single
file, you can reconfigure 'html-leaf-contains-contents' to true.

[originally from svn r10212]

this a couple of times in Halibut markup recently (in particular, it's
handy to have a typographical distinction between 'this term is
emphasised because it's new' and 'this term is emphasised because I
want you to pay attention to it'), so here's an implementation,
basically parallel to \e.

One slight oddity is that strong text in headings will not be
distinguished in some output formats, since they already use bolded
text for their headings.

[originally from svn r9772]