Generalization of the project information structure

^{Parts of this had originally been in a comment in anyother PR. But this PR was now narrowed down to the UI changes, so it may make more sense to summarize the points about the "data model" here:}

I think that the IProjectInfo is the central place that will have to be reviewed and possibly changed in order to generalize the project explorer as to become an "Ecosystem Explorer".

The id, name, description and link fields are generic enough to be applicable to basically everything, so they can probably remain as they are.

The other fields are already specific for software projects, and maybe even specific for glTF. Some of them have already been part of some discussion - for example, task might be changed to keywords...

In view of https://github.com/KhronosGroup/glTF-Project-Explorer/issues/88 , there would be entirely different properties - probably something like author and conference or publisher (nah, not all the possible BibTex properties, but maybe some of them...).

Now, the specific properties are currently "linked" to the UI part - throughout the code, without any abstraction: Starting at the IProjectInfo, they also appear in IUpdateFiltersAction, various functions, down to the tailwind.config.js, where the background color of one button is stored via { theme: { extend: { colors: { filter: { task: "#ffdac1", ... } } } } .... This makes it difficult to generalize anything, and every change (even just renaming task to keyword) would affect every part of the code (and I don't know how someone should find that tailwind config entry - it took me a while to figure out where this color comes from...).

I'm not sure about the possibilities or "best practices" for generalizing the UI-specific part, but maybe that can be decided later. Starting from the "modeling side", one could imagine structures like these:

interface IProjectInfo {
  id: number;
  name: string;
  description?: string;
  link?: string;
}
interface ISoftwareProjectInfo extends IProjectInfo {
  license?: ProjectLicense[];
  type?: ProjectType[];
  language?: ProjectLanguage[];
}
interface IArticleProjectInfo extends IProjectInfo {
  authors?: string[];
  publisher?: string[];
  language?: string[]; // Not the programming language here, of course :-) 
  ...
}
// Maybe even an "IGltfSoftwareProjectInfo extends ISoftwareProjectInfo"...

These properties could, very roughly speaking, correspond to the "database schema columns". Then, it would be necessary to be able to access these properties programmatically (and not with instanceof). I thought that it would be great to have something that describes the structure of entries similar to a JSON schema:

"entryStructure": {
    "name": { 
        "type": "string",
        "description": "The name of the project that will be displayed in the title"
     }
    "description": { 
        "type": "string",
        "description": "The description that will appear in the detail view"
     },
     ...
     "inputs": { 
        "type": "string[]",
        "description": "An array of strings that are the file extensions of input file formats"
     },
}

and basically make the IProjectInfo generic enough to be able to define the structure of an IProjectInfo with such a file. (And ... maybe this file could also have a "backgroundColorForTagFilterButton": "0xCAFEBABE" for each entry...)

One could probably make some simplifying assumptions for mapping this to the UI. For example, one could require that each property is just represented as an array of strings. Even if it is something like a publicationYear for an "Article": Modeling this as a string[1] looks quirky, but far less than trying to encode and process(!) arbitrary type information generically.

Start by reviewing the IProjectInfo model, IUpdateFiltersAction, the related functions, and tailwind.config.js, along with the discussion linked from PR 146 and issue 88. The issue does not define a settled design or acceptance criteria; completion would require an agreed generalized data model and corresponding UI access strategy.