Migrate from lodash to lodash-es

[Bengejd]

PR Checklist

PR Structure

• This PR has reasonably narrow scope (if not, break it down into smaller
  PRs).
• This PR avoids mixing refactoring changes with feature changes (split into
  two PRs otherwise).
• This PR's title starts is concise and descriptive.

Thoroughness

• This PR adds tests for the most critical parts of the new functionality or
  fixes.
• I've updated any docs, .md files, etc… affected by this change.

What

This PR migrates usage of lodash to utilize the lodash-es build variant for better tree-shaking support.

Why

lodash-es is the ESM build of lodash, which allows bundlers to tree-shake unused utility functions rather than including the entire library. Since this package targets modern bundler environments, using lodash-es reduces the final bundle size for consumers. It also addresses issues brought to light in #111.

Because lodash-es ships pure ESM, Jest cannot consume it directly in its default CommonJS environment. To support this, two changes were made to the dev/test setup:

• @babel/preset-env was added and configured via babel.config.js to transform ESM to CJS at test time
• transformIgnorePatterns in jest.config.js was updated to allow lodash-es to be transformed (Jest skips node_modules by default)

All tests are passing.

Known limitations

N/A

[fnando]

I just released 4.5.4-alpha.0 with this change. I tested this on browser, browser with importmaps, react-native and react-native with expo. They all worked! I'm going to give it another try on the weekend, and make a release if everything goes well!

[geoffharcourt]

@Bengejd would you consider using https://es-toolkit.dev/compatibility.html here? It's API-compatible with lodash/lodash-es, but much, much smaller.

[geoffharcourt]

Would it be possible to avoid the subdirectory-style imports and move to import { functionname } from 'lodash-es'? Asking because it's an impediment to aliasing lodash-substitutes like es-toolkit.