Implement a standard method for moving external libraries into /docroot/libraries

Problem/Motivation

We need external libraries to "end up" in the correct place after downloading them with composer. Currently, we use composer/installers to check for the "type" key in the libraries' composer json and move it to the proper place based on it's value (e.g., `type: drupal-module` is moved to `/docroot/modules/contrib`). This logic is defined in our scaffold project and other scaffold projects (like BLT and drupal-project do the same).

Additionally, BLT and drupal-project move packages with `type:drupal-library` to /docroot/libraries. The problem is, packages like enyo/dropzone don't provide any information regarding their type. So compoer puts them in /vendor where they can't be served.

Projects can individually modify the type value of a package in their root composer.json file. But this isn't an option for Lightning since Lightning doesn't have control over the root composer.json. We can add it to our scaffold project, but that wouldn't work for projects that use BLT or their own custom root composer.json. It's also not scalable and we don't have control over even lightning-project's composer.json file once someone implements it.

Proposed resolution

Option 1. Documentation

We could just clearly document that the end user is responsible for getting the library downloaded and into the proper place. But that's easier said than done.

Option 2. Provide an endpoint that modifies the type value of any package requested through it

This is kind of insane, but what if we implemented a "wrapper" endpoint around Asset Packagist (which already exposes all Bower and NPM packages to Composer)? This endpoint would forward all incoming requests to Asset Packagist and intercept, then return, the original responses. If a particular package's metadata is requested, the endpoint would change its type to "drupal-library", then return the metadata. In this way, all Asset Packagist packages would be exposed as drupal-library packages.

Option 3. Others?

Option 1 is likely to lead to confusion, broken builds, and issues in our queue. Option 2 isn't really sustainable unless it was officially supported by someone, and I don't think the Lightning team can volunteer to do that. So we obviously need a better solution.

Remaining tasks

Come up with a better solution - or find someone/an organization to support Option 2 if there is a consensus around it