docs/clean: formally deprecate rollupCommonJSResolveHack

[agilgur5]

Summary

Formally deprecate rollupCommonJSResolveHack as it's been obsolete since 0.30.0

Details

• this has had no effect since Fix duplicate output with multiple entry points on Windows (host normalization) #251

  • that changed the code to always return OS native paths via the NodeJS Path API
    • so setting rollupCommonJSResolveHack would make no difference either true or false
      • effectively, it's as if it's always true now

• formally state now that this is deprecated in the docs

  • as well as when that occurred and what it means

• also add a warning in options similar to the existing one for objectHashIgnoreUnknownHack (from cd76b42, which was added to my first major contribution back in (fix): upgrade object-hash to support async/await syntax #203 🙂 )

• remove the resolve dependency as well

  • it turns out something in the devDeps still uses it, so it didn't get fully removed in the package-lock.json
  • resolve was never needed anyway as we could've used NodeJS's native path.resolve or require.resolve instead (noted this at the bottom of rpt2 does not resolve pnpm symlinked dependencies #234 (comment))
    • resolve was created for browserify after all, where one can't use NodeJS APIs
      • but we run on NodeJS and can and already do use NodeJS APIs, including both path.resolve and require.resolve
  • I actually started this PR just to remove the dep, then realized the entire code path is obsolete 😅 😅

References

• Per above, this was made obsolete in Fix duplicate output with multiple entry points on Windows (host normalization) #251
  • Which turns out is a fix for code splitting broken on Windows #169
  • And a workaround for Code splitting doesn't work when plugins resolve imports in POXIS format on windows rollup/rollup#3094
    • Should rollup normalize directory separators in resolveId paths? rollup/rollup#2952 seems to be a more-or-less equivalent issue as well
• Original issue in rollup-plugin-commonjs: namedExports is using non-normalized resolved module path as module id rollup/rollup-plugin-commonjs#177
  • Which was fixed by Normalize ids before looking up in named export map rollup/rollup-plugin-commonjs#406
    • Related: I actually don't think your old comment there is correct; so long as commonjs is internally consistent, it shouldn't matter what kind of paths are passed to it, as it is normalized to the same string either way
  • and released in 10.1.0, which seems to have been the last version before the move to @rollup/plugin-commonjs