feat(global): move from lodash to remeda

[DenisValcke]

Hi @IbenTesara

I've tried switching out Lodash for either a native JS option or a Remeda alternative.

All checks pass (format, lint, test & build), but I would suggest having a critical look and maybe testing yourself as well seeing as this is a change that is pretty wide and affects pretty much all packages.

For transparancy. I was a bit doubtfull about the libs/javascript/rxjs/src/lib/operators/populate/populate.operator.ts changes required for the get and set for lodash. So I asked Claude Code to weigh in on my options. the suggested alternative was, in my opinion, pretty solid but required some additional tweaks. So the setByPath and getByPath are mostly contributed to that specific AI tool, with validation and fixes from my end.

Moving away from Lodash solves two things:

• Lodash hasn't been properly mainted for about ten years. Some effort has been made this year (2 releases) to address some longstanding bugs and security issues, but that's pretty much it.
• Lodash is causing ESM warnings when making production builds.

I've considered using es-toolkit instead of remeda because they have a 1:1 compatibilty drop-in package. However, they themselves state that this should be considered a transition method and not a definitive solution. If refactoring is required for both and a lot of Lodash utils can be converted to native JS, the choice between remeda and es-toolkit becomes subjective. My reasoning for remeda is that it leans more towards the functional, ramda way of working.

Let me know what you think.

[DenisValcke]

I wasn't sure about seperating these utilities seeing as they are only used within this operator.

So the question is, do I export them here, but not in the barrel, so they are locally available should this ever come up anywhere elese? Or do I remove the export and simplify the barrel again to export *?