refactor getSupportedChartTypes() to clarify the rules by chartType

[siosonel]

Description

... instead of using procedural code. Closes #2229

Tested with TermdbTest only, other datasets will need to be migrated in sjpp repo. The chart buttons in localhost should match the ones in prp1 (11 charts).

Tested with http://localhost:3000/testrun.html?name=*.unit and cd client && npm run test:integration.

Checklist

Check each task that has been performed or verified to be not applicable.

• Tests: added and/or passed unit and integration tests, or N/A
• Todos: commented or documented, or N/A
• Notable Changes: updated release.txt, prefixed a commit message with "fix:" or "feat:", added to an internal tracking document, or N/A

[xzhou82]

this is a good design. it can be improved by removing profile charts. this should only define general chart types that can be determined by term type availability. profile charts and any other special purpose charts are only defined in their own ds.cohort.specialCharts[]. and will be added to supportedChartTypes as-is.

[siosonel]

So that would mean that any chartType that's listed in specialCharts, is not meant to be be listed in hiddenCharts, right? In other words, if it's listed in specialCharts, just ignore hiddenCharts for it.

[xzhou82]

correct. special charts will simply be added and will not be explicitly coded here, this simplifies logic

[airenzp]

Maybe we can have a method that does a switch with cases for the charts with more complex logic and a default behaviour, something like:

isSupported(chart)
{
switch(chart):
...

default:
return specialCharts.includes(chart) && !hiddenCharts.includes(chart)
}