Migrate core back to prelude

[webdevred]

Pros

1. Reduced dependencies in the default build
   The main jbeam-edit library and executables no longer depend on relude or its transitive dependency unordered-containers.
   This results in slightly faster builds, fewer transitive dependencies and simpler dependency management.

2. Still keeps Relude where it adds value
   The extra internal libraries (jbeam-edit-transformation, jbeam-language-server) still use Relude for its safer Prelude and functional helpers.
   This keeps their code expressive and safe without adding unnecessary dependencies to the main build.

3. No functional loss in the default build
   In the core code, Relude was only used for Show/Read instances, which was only used by test dataset generation and in the test suite.
   The standard Prelude provides the same functionality; the only difference is slightly lower safety, which is acceptable in this controlled context.

4. Cleaner and more maintainable configuration
   The global mixins setup has been removed.
   Relude is now applied locally via a reusable _jbeam-extra-lib YAML anchor where needed.
   Each component’s dependencies are explicit and easier to reason about.

5. Improved interoperability and contributor friendliness
   The default build now uses only standard Haskell dependencies (base, mtl, etc.).
   Developers familiar with typical Haskell projects can build, test, and contribute without needing to understand Relude’s custom Prelude system.

Cons

1. Slightly less safety in the core/test code
   Test dataset parsing now uses Prelude.read, which can fail at runtime.
   Since this data is generated and controlled, the risk is negligible but technically it is less safe.

2. Mixed coding styles across components
   Core modules use the standard Prelude and mtl, while the extra libraries use Relude’s safer Prelude and conventions.
   Contributors may need to be aware of which Prelude is active in each context.

3. Very modest dependency reduction
   Only two dependencies (relude and unordered-containers) were removed from the default build.
   Most other dependencies remain, so the overall reduction in dependency footprint is small.
   When I started this, I imagined the amount of reduced dependencies to be bigger.

---

I will think about if I should merge this or not for a while, I think.