Core operations of GDT

[grayside]

The "core" operations of GDT are the things that belong in grunt help, that are the high-value, task-oriented features of the system. At present, this is somewhat clouded, and we present developers with some operations with a small learning curve and limited standalone value.

These top-level operations seem to be the following, and should align with top-level configuration keys, and operate as conceptual or even literal grouping of secondary operations.

• Build: Drush Make, Scaffold, Post-Build operations, e.g., theme dispatch.
• Validate: phplint, phpcs, eslint > modules
• Analyze: phpcs, phpmd, eslint > modules
• Package: <Choose your Flavor>
• Install: Install a working Drupal site
• Serve: Simple hosting for the Drupal site. If build/html is empty, should run Build.
• Test: Run tests, because it takes a while or needs complete/working Drupal code. If build/html is empty, should run Build.
• Watch: Watch for GDT-managed code.
• Default: Composer:Install, Validate, & Build

Further, there are "extended functionality areas:

• Project: Git Repository, Project name, Default URL, Alias
• Scripts: Our "operational scripts" broker, similar to npm scripts.
• Themes: For close integration with theme tooling.

This riffs on #251, #169. Much like #169, it takes the position that for reasons of DX, GDT should take an opinionated position about what it's providing, rather than the "light" approach alternative of simply aggregating useful tools from npm. The current middle-ground is confusing.