[Policy] Dependency evaluation critera

When adding a dependency to Drupal core there are several topics to consider before making use of the library. Today this is summed up in the documentation page Core dependency release cycles, security information, and evaluation criteria.

A few examples of what it takes to add a dependency:

• #3060153: Use PostCSS in core, initially only for Claro
• #2550717: [JS] Replace jQuery.cookie with JS-cookie and provide a BC layer
• #3036210: Add justinrainbow/json-schema as a composer dependency so JSON:API can use it to validate its responses
• #3074267: Replace jQuery UI position() with PopperJS
• …

Problem/Motivation

There are no difference in the evaluation of runtime, build, and development dependencies. This process is not sustainable for JavaScript:

1. JS libs tend to be much smaller than PHP libraries, and depend on many, many packages
2. Because of their size most dependencies don't have release schedule, or a security policy, or anything beside a well-meaning maintainer
3. Even 'big' projects don't have the founding/structure to provide what we would want from our runtime dependencies (see the rollup issue)

For example the testing suite of the once library brings in 408 node packages #3199444-5: Dependency evaluation theoretically we should go through the dependency evaluation for each one.

Proposed resolution

1. Introduce a different set of rules for build and development dependencies.
2. for build/dev: we should have the assumption that when no policy exists we defer to the license. Usually that means: no guarantee.
3. Rely much more on tooling for build/development dependencies to scan periodically for security issues (like it's been set up for once) to help mitigate point #1 and #2

Remaining tasks

Agree on something :)