Move the supported table out of README

[ekohl]

This changes the workflow to have a rake task to create a database.md file and then render that into the generated documentation.

The release process is also enhanced to include the generated database.md file. This should allow sites like rubydoc.info correctly render it as well, though this hasn't been tested.

It also introduces a GitHub Action workflow to build GitHub Pages with the generated documentation. That means that the documentation should always be up to date and no manual steps are needed anymore. It also saves a lot of noise in the git log.

Please review carefully. Some notes:

• Have we set up GH Pages for voxpupuli/facterdb?
• Is the discoverability still all right?
• Doesn't this also build for all forks?

[smortex]

I guess we do not need to bundle this file into the gem:

Suggested change

	s.files = `git ls-files`.split("\n") + ['database.md']
	s.files = `git ls-files`.split("\n")

If I am wrong and we want to do so, it may make more sense to require 'bundler/gem_tasks' and change the Rake task to something like:

file Dir['facts/**/*.facts'] => 'database.md' do

that way, when we build with rake build the md file is updated if necessary before packaging the gem.

[ekohl]

I guess we do not need to bundle this file into the gem:

I wasn't sure: I think https://rubydoc.info/ generates the docs based on the gem, but that's something we should play with. Could even be a follow up step.

If I am wrong and we want to do so, it may make more sense to require 'bundler/gem_tasks' and change the Rake task to something like:

Interesting idea. I'll think about that.

[bastelfreak]

@ekohl stupid question; but: How much value does the table provide? Maybe we can just drop it?

[ekohl]

I think it can be useful to some, but I don't recall using it myself.

[yakatz]

I don't think it is useful in the current format - it is way too big and doesn't tell you quite enough information, for example, if you want to know if your OS and faster version has x86 facts.

[ekohl]

I agree. Perhaps it should be split in either per OS or per facter version. Perhaps generate both

[bastelfreak]

to be fair the table is way smaller after dropping all the ancient versions. See: https://github.com/bastelfreak/facterdb/tree/facter3?tab=readme-ov-file#facter-version-and-operating-system-coverage

[yakatz]

Smaller is good, but still, is it useful? I would argue rather than a table, maybe it makes sense to make it a list or even multiple lists, each sorted a different way: by OS, by Facter version, and by architecture.

For example:

By OS:
- Debian 11
  - Facter 4.5: x86_64
  - Facter 4.4: x86_64
- Debian 12
  - Facter 4.5: x86_64
  - Facter 4.4: x86_64, i386

By Facter:
- Facter 4.5
  - Debian 11: x86_64
  - Debian 12: x86_64,
- Facter 4.4
  - Debian 11: x86_64
  - Debian 12: x86_64, i386

By Architecture:
- x86_64:
  - Debian 11: Facter 4.4, Facter 4.5
  - Debian 12: Facter 4.4, Facter 4.5
- i386:
  - Debian 12: Facter 4.4

I would also say each list type should be its own .md

If people think that is reasonable, I can try a PR.

[yakatz]

Merged in #327