Define a more managable workflow to keep track of requested new content types

There are many content types that Magika does not support, and github issues about new requests are piling up (thank you @MichaelHinrichs & others!). While these issues are *very* valuable, especially when they contain information about the file format itself and pointers on where we could find samples, they are making it quite difficult for newcomers to find open issues.

To address this issue, this is what I have in mind:
1) keep asking the community to open github issues as a first step, so that we can have an initial discussion.
2) maintain a low-overhead sort-of knowledge base (KB) as part of magika docs to keep track of the currently supported and unsupported content types. This would help us having a clean overview on what's going on, with the relevant information properly systematized.

This is how the KB could look like:
1) main "supported content types" markdown file with a table of content types. First we list the currently supported, then we have a table with currently unsupported.
2) For each of the currently unsupported content types, we have: a) tags to indicate metadata, e.g., their importance (supporting Dockerfile is much more important to support some very niche configuration file of some old game), b) optionally, a link to an additional markdown file for that specific content type (which would contain all the useful info provided in the github issue).

For the moment, for those new content type requests for which we have all the info, I'll close them and add a new label "content type to import in KB" so that we can keep track of them. Once we define the format of the KB (or we find an alternative solution), then we we go through them an import everything.

Thoughts?

@invernizzi @MichaelHinrichs?