feat(jsii): enforce peer dependencies

[eladb]

If a jsii module exposes a type from a dependency in it's public API,
jsii now enforces that this dependency is also defined as a "peer"
instead of a normal dependency.

This tells npm that if a user of this module already
installed a compatible verison of this dependency in their
closure, npm will pick the one installed by the user (as a peer)
instead of fetching another version.

jsii will also flag these dependencies as "peer" in the jsii spec. At the
moment, this won't have implications on generated language packages,
but in environments that have support for peer dependencies, we should
make sure the module's metadata reflects this idea as well.

A utility called "jsii-fix-peers" is included. It will inspect .jsii
and package.json and will add "peerDependencies" to package.json
for all dependencies that have types in the public API.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[rix0rrr]

<3 that you're adding the attribute it to the jsii manifest, but </3 that it's called "peer". Feels like very NPM-centric terminology. How about talking about "public" vs "private" dependencies, or "interface" vs "implementation" dependencies?

[RomainMuller]

This is a regression !

[eladb]

Sorry, just merge issue. Fixing.

[RomainMuller]

I agree with @rix0rrr that the "peer" name is not ideal, but I disagree with the suggestions as they would seem to imply deeper semantics...

[eladb]

@rix0rrr I think it's okay to be npm-centric in the jsii manifest because the source /is/ package.json and is a key part of the jsii model. Since peer dependencies are a complex topic, I feel "latching on" to the "peer" semantics of NPM at least gives the user an entrypoint to understand what's going on. Otherwise, we would need to either reproduce all the documentation ourselves or just tell people "this is like 'peer dependencies' in npm", which then, we might as well, just call "peer".