Static HTML docs generator

[farism]

This PR upgrades the mint docs generate command with static HTML generation.

I tried to model the generators after the existing json generators. At first I couldn't decide if I should just split the html and json generation up into two separate commands and file structures but I think keeping them together like this makes a bit more sense and is cleaner.

At the moment, the css is being pulled from mint-lang.com, with some overrides and some net new css. I did this just to get started easier. We need to consolidate and move this css somewhere. My thought was putting it into the assets folder so it is baked, and then generating a standalone css file that lives alongside and is referenced by the html files. I would like some direction on the css situation before continuing.

Other notes

• I had a hard time deciding whether the --git-url, --git-url-pattern should be settings in mint.json, but I think the desire is to keep the mint.json as lean as possible
• In most cases you don't need to use the --git-url and --git-url-pattern flags anyway, since the GitSource class handles finding this information from the local repository. However, this class may be unnecessary complexity and we should just always require the flags to be passed if you want links properly generated.
• I would like to enable people to write additional content in the form of markdown and automatically list it alongside the README links at the top of the sidebar, called "Guides" or something like that. But I don't know how this would work. An additional CLI flag with a pattern to markdown files? Another reason to expand mint.json perhaps? We also talked about adding an source-examples key or something like that, maybe it could interface with that?
• Should these docsites rely on cdn at all, or should it generate all the necessary assets - highlight.js etc - so that docs can work in offline mode?
• How do we generate previous versions of the doc site? My thought was to read all the local tags, but someone might have tags that are not releases. Really what we want to do is fetch valid releases and their respective refs from the remote repo, but now we're dealing with various service APIs (github/gitlab/bitbucket)
• How should this all be documented? I thought adding a guide to mint-lang.com/guide made sense.
• We should have a mint logo somewhere with a link to main mint website, but not sure where to put it. Bottom of the sidebar maybe?

[gdotdesign]

Thank you for this PR! Really great stuff 🎉

• CSS: Yes, we should bake the CSS in and generate it with the documentation.

• Git URL: This should be called source-url in the mint-json somewhere, not sure where yet since it would be only used in the documentation.

• Additional pages: There should be a discussion about this before we implement anything. I feel it's connected to the storybook feature we discussed on Discord.

• CDN: The generated site should not rely on CDN (or external links of any kind). There are two reasons for this:

  1. It's possible that they will break in the future (20+ years) when the links are no longer active.
  2. As you said, this way they will work offline.

• Previous versions: Not sure if we need to. I think it will be up to the author or the package's site who publishes the documentation, both have access to the older versions.

• Documentation: Yes, a page in the guide makes sense.

• Mint Logo: I don't think we need to put that there, it would be nice for SEO but only for that.

highlight.js should be replaced with the semantic tokenizer so it's one less dependency and more accurate results 🙂 we need to create CSS styles for the tokens, though.

Also links to GitHub are nice but I like having the source code inlined so maybe it can be a flag the defaults to inline and can be set if the author like it better.

[farism]

Thanks for guidance, I tried to incorporate the feedback into the latest updates

• All assets (css, js, fonts, favicon) are now baked
• Uses semantic tokenizer for mint codeblocks
• Adds source-url to mint.json - it's top level for now, I think that actually kind of makes sense and matches most other package manager manifest files
• Updates styles to be closer to new design

Notes:

Configuring source-url is now the only thing required to generate source url links
--git-ref flag defaults to master (maybe it should be main?)

I know you said you prefer "view source" being embedded into the docs rather than linking to GH, but if you are okay with that as a followup I think this is probably ready for initial CR.

[gdotdesign]

I'm trying out the PR and ran into some issues (running it with /usr/bin/python3 -m http.server) and fixed some of them:

• The generated docs cannot be run straight in the browser locally because the assets paths are absolute /assets/fonts.css
• A minor thing, these icons have a white background [fixed]
  
• URLs are not pointing to the HTML files: localhost:8000/modules/Clipboard#set should be localhost:8000/modules/Clipboard.html#set [fixed]
• fonts are not loading because of path issue [fixed] :
  

[farism]

Great, thanks for the fixes. Admittedly I never actually tried loading the files directly in the browser, I only ran it through a webserver. The base url logic can probably be improved.