Slightly reformat quick facts table

Use a definition list for the Windows support, to eliminate a
Sphinx warning about a missing definition.
While here, use em and en dashes instead of hyphens, as appropriate.
Make krb5_trace_info a typedef

Our doxygen-to-sphinx documentation bridge only processes typedefs
and not structure definitions, since we almost universally use
typedefs for our data structures.  krb5_trace_info is the sole
exception, so bring it into the fold.
Update doxygen markup in krb5.hin

A few places were using the standard C /* comment */ form, but
this is rendered poorly by doxygen through to our Sphinx bridge.
Use the special /**< comment */ form to get doxygen-specific behavior.
If the standard C comment form is used, the full comment (including
start and end markers) is included in the value of the macro, and
Sphinx then tries to treat the end of the comment as the start of
inline markup with no corresponding end-string, which is a warning.
Using the doxygen form of the comment, the contents of the comment
are put in a separate paragraph block, which is inserted in the
body of the generated RST document.

The markup for krb5_rd_priv() had a line that ended with an @c
markup statement without a symbol following it.  This confused
doxygen into not parsing any more of the comment.  The beginning
of the next line is a macro identifier with markup to auto-linkify it.
In RST, it is not possible to have a link and a terminal font on the
same text, so removing the @c is the appropriate fix.

There are also eleven deprecated functions which are replaced by
the krb5_c_* family of functions.  However, referring to this class
of functions as the "krb5_c_" class of functions results in Sphinx
attempting to interpret this statement as a link to a label elsewhere
in the document, and no such label exists.  To avoid this warning, use
"krb5_c_*" to refer to the class of functions, which is arguably
more correct anyways.

ticket: 7447
tags: pullup
target_version: 1.11
Fix overflowing cell in HTML table

sphinx-build defaults to the 'tabulary' environment for tables,
but uses regular 'tabular' for those involving literal blocks,
since tabulary does not handle them properly.  It seems that this
deficiency of tabulary also applies to inline literals, which
are rendered as \code{} sections by the latex builder.
Fortunately, sphinx provides a workaround to force a particular
column specification for the table.

The requirement for a table:: statement after the tabularcolumns::
statement is very poorly documented.

ticket: 7447
tags: pullup
target_version: 1.11
Handle adjacent notes from doxygen more correctly

The Doxygen documentation seems to claim that adjacent @note entries
will be collapsed into a single "note" element, as separate paragraphs.
This seems to be reflected in the XML output, multiple <para> entries
in a single <simplesec kind="note"> with a <simplesecsep/> element
between them.
Our XML-to-RST converter gets the entire contents of the simplesec
element, parsed into a unicode string with a single newline between
paragraphs.  Paragraphs seem to always start with two spaces, though
I have not tracked down the origin of this behavior.  Prior to this
commit, we would just output this entire unicode string directly.
Since our template puts a tab character before the note string, this
means that the first paragraph is indented by a tab and two spaces,
and the second paragraph by just two spaces.  Sphinx warns about this,
as "block did not end with blank line; unexpected whitespace", and
the paragraphs are indented differently within the note.
Fix the warning by checking for newlines in the interior of the
parsed unicode string, and introducing the appropriate whitespace
for the Sphinx parser.

ticket: 7447
tags: pullup
target_version: 1.11
Render macros as literals

Some convenience macros are referring to and dereferencing pointers,
and Sphinx will get a bit confused trying to inerpret this as markup.
There should never be any markup intended to be interpreted in the
value of a macro definition, so we can silence this class of
warnings by treating them as literals.  (In some sense, they actually
are literals, too.)

While here, do not generate documents for macros that only cause a
symbol to be defined, that is, a literal "#define MACRO" with no
initializer.  The generated documentation is not useful in these
cases, and attempting to use the markup for a literal string with
an empty string produces unfortunate results.

Also, strip leading and trailing whitespace from the macro name,
since this also causes problems with the markup.
Remove outdated include

We no longer generate KRB5_OLD_CRYPTO.rst since the macro does not
have an initializer.  Don't try to include it in the table of contents.
Handle multiline macro definitions

Compress them onto one line for printing in the generated table.
Add some files previously missed

Sphinx warns that these documents weren't included in any toctree.
Include them.
(TRUE and FALSE are perhaps a bit questionable...)
Remove last "document not in toctree" warnings

There were two of them, for notice.rst and mitK5license.rst.
The former is included in the latter, which is linked to from
the mitK5features document but not listed in a table of contents
otherwise.  Includes are processed unconditionally, so we can
add notice.rst to the exclude_patterns array (formerly unused_docs)
and its content will still be included.

If we attempt to do the same for mitK5license.rst, it is not processed
at all, and the attempt to link to it will fail.  Instead, put a dummy
table of contents in the mitK5features document (which links to the
license document), with the "hidden" attribute.  This satisfies the
Sphinx need to know where all the input documents are without changing
the displayed table of contents.