Add a proxy for the deprecation bit, and return placeholder values in
case version or message are missing.

Deprecation annotations should have a version and a message, but neither
is mandatory.

If find a deprecation node, we explicitly mark the element as
deprecated.

Include the description's TOC in type templates

See merge request GNOME/gi-docgen!138

Like we do for extra content files, we should generate a TOC of the
sub-headings inside the description of types: classes, interfaces, and
structured data. This way it's easier to navigate to sub-sections, and
to get their location for links.

This way we can generate an index of the sub-headings inside the
description of a type.

Revert "Add tooltips to class hierarchy edges"

See merge request GNOME/gi-docgen!137

This reverts commit 15023b41.

The commit broke the graph generation, and will need to be re-done.

generate: Improve the TOC for content files

See merge request GNOME/gi-docgen!136

We can omit level 1 headings if there's only one of them, as it usually
means the title of the document; we should always show level 2 headings,
as they are more common in all cases.

Add tooltips to class hierarchy edges

See merge request GNOME/gi-docgen!134

Currently, when hovering over an edge between a class and its ancestor,
it gives a tooltip similar to `this--ancestor_0`.

This is not really informative and is probably even worse for people
with screen readers, as they can't see the diagram and can only get
confused by it.

Replace it with `$TYPE extends $TYPE` or `$TYPE implements $TYPE`.

enum template: Generate links for enum values and add some missing titles to the navbar

See merge request GNOME/gi-docgen!135

The current enum template only mentions the "Description" title (and
"Functions" if applicable). However, depending on how long the
description might be, it's a good idea to also add a link for quick
access to the members. There's also an error domain below that, so let's
link that as well.

This commit adds an anchor to the enum member, and uses the name of the
member (as specified in the GIR) to create a link.

Related to https://gitlab.gnome.org/GNOME/gi-docgen/-/issues/121

content files: generate a navbar with the headers

Closes #124

See merge request GNOME/gi-docgen!133

We're already using the ["toc"] extension of the Markdown module, which
allows us to get the header hierarchy after parsing as a list headers,
each represented as a recursive `dict`.

["toc"]: https://python-markdown.github.io/extensions/toc/

gir: Do not require a deprecation message

See merge request GNOME/gi-docgen!132

Symbols can be deprecated with just a version identifier, even though it
is preferable to have a message.

css: style keyboard shortcuts

Closes #122

See merge request GNOME/gi-docgen!131

- stay close to what libadwaita does

Fixes https://gitlab.gnome.org/GNOME/gi-docgen/-/issues/122

Fix typo in link

See merge request GNOME/gi-docgen!130

tests: Add a unit for LinkGenerator

See merge request GNOME/gi-docgen!129

We need to test both the link regular expression, to ensure it matches
both the plain links and the link with additional text; and the
LinkGenerator class.

generate: Include bits in structure fields

Closes #119

See merge request GNOME/gi-docgen!127

Add pylintrc

See merge request GNOME/gi-docgen!128

Make pylint not complain so much.

If the GIR parser found them, we should include them in the C
declaration.

Fixes: #119

template: Add blurb when eliding inherited methods

Closes #112

See merge request GNOME/gi-docgen!124

Makes it easier to understand that you're supposed to go and look at the
ancestor or interface page.

Fixes: #112

generate: Improve classification of pointer arguments

Closes #117

See merge request GNOME/gi-docgen!126

template: Add more contrast to the dimmed text class

Closes #116

See merge request GNOME/gi-docgen!125

Arguments marked as in-out can also be nullable, which means they can be
set to NULL.

A nullable argument is, by definition, already a pointer argument; we
don't need to check for additional pointers.

If an argument is of a fundamental type, the direction is out or in-out,
and it has a single pointer, then we don't need to classify it as a
pointer argument, as it's really an out argument, and the fact that it
uses a pointer is merely how C implements out arguments.

We use the dimmed text for a bunch of text, so it should have better
contrast to increase readability.

Fixes: #116

generate: Handle missing type information in arguments

See merge request GNOME/gi-docgen!123

We should use the C type of the argument as much as possible, but we
should also have fallbacks in place for when the argument does not have
a C type—for instance, in arrays/lists and signals.