Update mdbook

[meator]

closes #840

I don't have much experience with HTML/CSS, feel free to take over this PR.

The first part of this PR "rebases" the theme files from base mdBook v0.4.14 to mdBook v0.4.43 (current version of mdBook package). This was done for several reasons:

• Adding newer and newer things on the old base can have negative effects.
• I split this update into two commits. The first commit overwrites void-docs theme files with the default ones and the second one applied void-docs specific changes. The second commit nicely shows how void-docs configuration differs from the default one (this comparison is much more difficult to make with the current code, but I did it, see "Void's changes to mdBook's default theme" in https://github.com/void-linux/void-docs/issues/840).

The next step is to actually fix the issues in #840. You can see my attempts in my "UNFINISHED" commit.

Things to consider after solving this issue

The ghcr.io/void-linux/infra-mdbook container will have to be updated.

Once that's done, this line will have to be updated to point to the new container. I am not closely familiar with Void's infrastructure, more steps may be necessary.

The void-docs package should be revbumped once this issue gets resolved.

[meator]

I have dealt with similar issues before (1. a utility provides a default "template" file 2. a project overwrites the template file and uses the modified one 3. updates to the utility make changes to the template file which do not propagate to the project using it, because the project completely overwrites it). This is usually desirable behavior, but it means that the project will not get any new features introduced in the updates to the template and it is prone to breakage when backwards-incompatible changes get introduced (like https://github.com/rust-lang/mdBook/issues/2685).

I usually try to solve them by not completely overwriting the entire thing, but trying to overwrite just the part that needs to be changed. New modifications to the "template" file made by updates to the utility (here mdBook) get propagated to the project that way.

There are two ways I know of to achieve this:

1. Use options such as additional-css which append to the template instead of overwriting it.

   This solution isn't applicable everywhere.

2. During configuration phase of the book build, generate a default template directory, apply a patch stored in the repo modifying the necessary files and then use this patched theme.

   This approach has several advantages:

   1. It works for things which do not have a way to append configuration (like additional-css above).
   2. The patch file stored in the repo clearly documents in what ways does the local configuration deviate from the default one (no need to manually obtain mdBook v0.4.14, generate its default theme and diff it to void-docs one like I had to do).
   3. If the patch doesn't apply (because an update to mdBook changed the patched data), the docs will not build. This is a good thing, if an update to mdBook made breaking changes, the patch should be reassessed and fixed. The current theme overwriting mechanism would continue "working" in that case.

   This approach has several disadvantages:

   1. It is slightly more complicated to implement, it adds a build time dependency on patch or git am.
   2. If a breaking change is made to a section of the theme data which is not modified by the patch, the patch application will still succeed, but the change could negatively affect void-docs.

What do you think about this approach?

[meator]

If the approach described above gets implemented, commits following my "Reapply void-docs theme changes" commit (including the commit itself) could become the base of the patches which would be applied during build. This is another reason why I split the "rebase" into two commits.

You may find that I'm overthinking this (which may be true), but my (limited) experience shows that tools like mdbook tend to introduce a lot of breaking changes in their updates especially when they are heavily configured (which is the case here). This isn't the last time issues like these will occur. And even if mdBook succeeds in being backwards compatible, getting new features implemented in new versions of mdBook would be nice (the current system prevents this, because the theme files are static, they are unaffected by mdBook updates).