[chore] Re-use loadEnvFiles from cli-helpers lib, elimininating code duplicatation

[Philzen]

While investigating for #11882 i stumbled over the fact that those lib files were almost identical twins. Unless there is a very, very good reason to have both around this PR determines the single-source-of-truth to be in @redwood/cli-helpers and drops the other one, effectively reducing our technical debt here.

No need to preserve the file in the cli package, as it had an identical git history up until 36fa1dd, which was 10 months ago. Since then, the version in @redwood/cli-helpers had four more commits, so it should be the better version.

This is also a good preparation for further investigation into (and hopefully a timely fix for) #11884.

[Tobbe]

People are deep-importing from our packages. So when we remove something like this we need to make a note of it in our release notes. It sucks this has to be marked as a breaking change. And no one is probably actually importing some random cli export... But it is what it is...

[Philzen]

has to be marked as a breaking change.

So you are saying that people are deep-importing from @redwood/cli?!? In a typical project i cannot even access that package 🤔

What i can do though is explicitly install @redwood/cli and then, yes i can do import { loadEnvFiles } from '@redwoodjs/cli/dist/lib/loadEnvFiles'.

My suggestion for this PR would therefore simply be to keep the file as a stub that just re-exports it. So it won't be a breaking change, right?

This PR would then be compatible for release in a non-major version bump, and we can do a separate one that simply removes that stub.

[Philzen]

People are deep-importing from our packages. It sucks this has to be marked as a breaking change.

@Tobbe Problem avoided via 5686f64

So when we remove something like this we need to make a note of it in our release notes.

When this is merged, it's as simple as reverting that commit in a separate PR which will be the breaking change for the next major.