Exclude bundled library folders from scanning for modules

[laryn]

Description of the bug

Backdrop modules in general will try to bundle a library where possible to make it easy for end users to install via the Project Installer. (Ideally, it is still possible to manage libraries manually with Composer or Composer Manager and forgo loading the bundled library if it's already loaded elsewhere, but the packaged modules do still contain the bundled library, even if it is not used in this case). With simple libraries this is not usually a problem, but as noted in the queue for GAuth, with complex dependencies, the libraries that get bundled can be very large, and because they are within the modules/ folder, every subfolder inside of the bundled library gets scanned to see if it contains more modules.

I propose that we:

• standardize a recommended folder name for bundled library/libraries (currently it's a little bit of a wild west for naming, library or libraries or ???). My suggestion: library libraries and vendor
• exclude that directory from being scanned.
• encourage relevant modules (ie. modules with substantially sized bundled libraries) that use alternate folder names to switch to this recommended naming

Here's a xhprof demo I did on my local:

For three scenarios (1. no changes; 2. download GAuth; 3. download GAuth and exclude 'libraries' from scanning) I went to the modules page and cleared caches three times through the admin menu. Averages of the three loads:

1. Control (no changes):
   • wall time: 1,136,894 µs
   • cpu: 617,667 µs
2. Download GAuth:
   • wall time: 1,323,171 µs
   • cpu: 733,514 µs
3. Download GAuth and exclude 'libraries' directory from scanning (since that's what the library folder is called in this scenario):
   • wall time: 1,173,573 µs
   • cpu: 632,967 µs

This seems significant, given that it's only one module being tested here!

[yorkshire-pudding]

libraries is the recommended folder name from https://docs.backdropcms.org/creating-modules

[laryn]

Thanks @yorkshire-pudding, I've amended the PR and the issue description. That documentation could stand to be made more explicit if this gets approval.