[Feat] Simplified peerDependencies policy

Target Use Case

An idea for discussion.

Some modules now have a significant number of peer dependencies. @deck.gl/carto is one example, with seven peer dependencies, soon to be eight, which increases the complexity of setup for new users.

As a maintainer, it's not always clear to me which modules belong in dependencies vs. peerDependencies, or whether there's an established policy. See the @luma.gl/* dependencies here:

https://github.com/visgl/deck.gl/blob/fa029dddebc43f350cef07cf8e9fe86d98415c02/modules/aggregation-layers/package.json#L40-L51

Each time a peer dependency is added, or its version incremented, that is technically a breaking change under semver. Whether it breaks users in practice would depend on whether the package in question was already somewhere in the dependency chain, which is hard to predict.

Proposal

Perhaps a way to simplify this — while avoiding the "mismatched dependencies" risk — would be to take a policy that the relevant */core module is always a peer dependency, while any other visgl-related modules are production dependencies, unless there's some particular reason for an exception?

Because everything else depends on the */core modules, I think that could be a way to minimize what end-users need to install, while also ensuring that compatible versions are used.

Start with the linked modules/aggregation-layers/package.json dependency section and review the issue's peerDependencies and semver references. Compare how the relevant */core and other vis.gl modules are currently classified. Done would require an agreed dependency policy and a clearly scoped set of package changes, which the issue does not yet define.