Types for list, map and set

[lshala]

This PR adds Type classes for List, Map and Set.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 75.12%. Comparing base (47d6f94) to head (ffd8810).
Report is 1 commits behind head on main.

Additional details and impacted files

Files with missing lines	Coverage Δ
...in/de/fraunhofer/aisec/cpg/graph/types/ListType.kt	100.00% <100.00%> (ø)
...lin/de/fraunhofer/aisec/cpg/graph/types/MapType.kt	100.00% <100.00%> (ø)
...raunhofer/aisec/cpg/graph/types/SecondOrderType.kt	100.00% <ø> (ø)
...lin/de/fraunhofer/aisec/cpg/graph/types/SetType.kt	100.00% <100.00%> (ø)
...hofer/aisec/cpg/frontends/python/PythonLanguage.kt	91.74% <100.00%> (+1.85%)	⬆️

... and 3 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[maximiliankaul]

I approve of these changes in general.

Some nitpicking:

• I'm not really fond of using objectType to create built-in type nodes, as we already discussed. I'm aware, that the objectType function internally checks for built-in types (using primitiveTypeNames which feels wrong), but I'd prefer the frontend to be cleaner in this regard and use objectType when handling code like foo = Foo() and the languages builtInTypes for stuff that's build into the language. However, this would be too much for this PR and an additional PR (or issue) seems to be good here. Also, there are way too many typeOf, ... or similar functions. I'm confused which one to use.
• (Not really relevant as this PR is super small, but I would prefer to have this split in two PRs for the future, as it does 2 things: implement the new stuff in cpg-core and then use the new stuff in the language frontends. These new concepts should then be implemented for all other supported languages in respective PRs, too.)

[oxisto]

I approve of these changes in general.

Some nitpicking:

• I'm not really fond of using objectType to create built-in type nodes, as we already discussed. I'm aware, that the objectType function internally checks for built-in types (using primitiveTypeNames which feels wrong), but I'd prefer the frontend to be cleaner in this regard and use objectType when handling code like foo = Foo() and the languages builtInTypes for stuff that's build into the language. However, this would be too much for this PR and an additional PR (or issue) seems to be good here. Also, there are way too many typeOf, ... or similar functions. I'm confused which one to use.
• (Not really relevant as this PR is super small, but I would prefer to have this split in two PRs for the future, as it does 2 things: implement the new stuff in cpg-core and then use the new stuff in the language frontends. These new concepts should then be implemented for all other supported languages in respective PRs, too.)

FYI there is the primitiveType function that allows you to use/create the primitive types without having to manually look them up in the primitiveTypeNames map. One needs to be sure that the type exists though, because if it does not, a translation exception will be thrown. `objectType´ will do a soft check if it exists and if it fails it will create an object type.