Refactoring layout/node type mapping

[olemartinorg]

Description

Fixing a few issues:

• Our master-list of components can cause merge conflicts if forks try adding their own layout components, because we all have to maintain the master list. This change moves the list out from git, and instead auto-generates it in an ignored file (src/layout/components.ts, which is generated by running yarn gen, which should also happen automatically for all relevant operations). This should make a solution as described in Analysis: Template for app frontend #200 more feasible.
• The type definitions for each component before and after node hierarchy generation was confusing. The default used to be ExprResolved<YourType>, and if you had special needs (such as adopting children and including other LayoutNode objects in your post-hierarchy type), you had to manually override that in hierarchy.types.d.ts. This should now just be set in the component config to take effect.
• Renamed the folder for the Iframe folder to match its component type name (IFrame)
• Cleaned up and simplified some types. Now HComponent<T> and AnyItem<T> is practically the same (although the first one does not support groups).. 🤷
• Removing a sneaky disabled property that could be optionally set on all layout components, but was never read by any code.
• Moving the NotInLayout type. It was now very easy to move these property extensions (such as baseComponentId) to indicate that they are only present on nodes in the hiearchy (as that's what add these properties), not some magic extensions to the layout definitions.
• Making it possible for a component type to extend the LayoutNode class and construct the extended class in the hierarchy. This will make it possible for components to add functionality here, such as having a LayoutNodeRepGroup type.

Related Issue(s)

• Experiment: Storing the data model in a Context #1175
• Analysis: Template for app frontend #200

Verification/QA

• Manual functionality testing
  • I have tested these changes manually
  • Creator of the original issue (or service owner) has been contacted for manual testing (or will be contacted when released in alpha)
  • No testing done/necessary
• Automated tests
  • Unit test(s) have been added/updated
  • Cypress E2E test(s) have been added/updated
  • No automatic tests are needed here (no functional changes/additions)
  • I want someone to help me make some tests
• UU/WCAG (follow these guidelines until we have our own)
  • I have tested with a screen reader/keyboard navigation/automated wcag validator
  • No testing done/necessary (no DOM/visual changes)
  • I want someone to help me perform accessibility testing
• User documentation @ altinn-studio-docs
  • Has been added/updated
  • No functionality has been changed/added, so no documentation is needed
  • I will do that later/have created an issue
• Changes/additions to component properties
  • Changes are reflected in both src/layout/layout.d.ts and layout.schema.v1.json, and these are all backwards-compatible
  • No changes made
• Support in Altinn Studio
  • Issue(s) created for support in Studio
  • This change/feature does not require any changes to Altinn Studio
• Sprint board
  • The original issue (or this PR itself) has been added to the Team Apps project and to the current sprint board
  • I don't have permissions to do that, please help me out
• Labels
  • I have added a kind/* label to this PR for proper release notes grouping
  • I don't have permissions to add labels, please help me out

[bjosttveit]

Very cool! I like that you split the config and type config, much cleaner this way!

[sonarqubecloud]

SonarCloud Quality Gate failed.   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
12 Code Smells

56.7% Coverage
0.0% Duplication