In case we didn't set a `basePath`, `<AppPluginLoader>` would always use the current path as a `basePath`.
This can get problematic in case the Cloud Onboarding app tries to handle it's own sub-routes.
* Feature Flags: introduce a flag for enabling the Data Connections page
* Feature Flags: generate schemas
* Navigation: add navigation weight for the Data Connections page
* NavLink: add a comment pointing out where icon names can be looked up
* NavTree: add a new page called Data Connections
* fix(Api): prefix the navigation IDs with the parent ("data-connections")
* feat(Frontend): add a basic page with four tabs
* feat(Plugins): add a hook for importing an app plugin
* feat(Plugins): add a component for loading app plugins anywhere
* feat(Data Connections): load the cloud-onboarding app under the "Cloud onboarding" tab
* feat(Data Connections): generate a proper nav model to highlight active tabs
* test(Data Connections): add tests
* refactor(Data Connections): update temporary text content
This is only used as a placeholder until the tabs are under development.
* refactor(Data Cnnnections): move /pages to /tabs
* refactor(Data Connections): remove the `types.ts` file as it is not referenced by any module
* feat(Data Connections): only register routes if feature is enabled