Front-End Architectural Improvements

[cstns]

Description

No response

Which customers would this be available to

None

### Other
- [ ] https://github.com/FlowFuse/flowfuse/issues/4028
- [ ] Webpack: code splitting w/ dynamic imports https://webpack.js.org/guides/code-splitting/
- [ ] Webpack: tree shaking https://webpack.js.org/guides/tree-shaking/
- [ ] Webpack: Hot Module Replacement https://webpack.js.org/concepts/hot-module-replacement/
- [ ] controversial: extracting from forge app (currently serving static assets via fastify server)

### Separations of concerns
- [ ] #1991
- [ ] https://github.com/FlowFuse/flowfuse/issues/4029

### Prerequisites
- [ ] Improve e2e test coverage
- [ ] Extract common methods/data/computed props into mixins would allow us to detect repetitive paterns across components and ease our decision if certain data should be persisted in a store

### Code Cleanup / DX
- [ ] Create and use webpack aliases | Decouple components from namespaces
- [ ] Rethink fontend folder structure: images/data/stylesheets/ui-components/utils firectories

[Steve-Mcl]

Create and use webpack aliases

Doe that mean we get reduced DX?

Currently, importing a module by file path means we get a richer DX. When using aliases, the editor loses the definition and DX experience is less good.

[cstns]

We can overcome that! Any configured webpack aliases can be picked up by any IDE and most importantly eslint with a little bit of tinkering!

Please consider all the tasks as flexible suggestions rather than fixed requirements. They are not finalized or fully cohesive at this stage. I am using this epic as a starting point and a place to gather ongoing tasks and bugs that are related, while I work on refining the guidelines and organizing the tasks more coherently.

[Steve-Mcl]

Please consider all the tasks as flexible suggestions rather than fixed

Things written down tend to become gospel ;)

So, I only mention it this because we previously had this situation and why we moved away from aliases (don't wanna go backwards). But if you can make this work with our non monorepo dev-env in our IDEs, then great.