Reorganize to use build as only env and facilitate plugin development

[westonruter]

Here's where I ended up. The only thing I couldn't get working is changing the WP_CONTENT_DIR. I'm sure there are other things that aren't ideal as well, but this where I had to stop.

Fixes #3.

[westonruter]

I think this is actually working now. I had to restart Docker because file changes stopped syncing.

[westonruter]

@felixarntz with the current state of the PR, I can now run lando npm run build for the AMP plugin. But running lando phpunit for the plugin is broken now, in spite of the .env 😕

[westonruter]

@felixarntz ok, I have a workaround for setting .env for PHPUnit, but it's not ideal.

Overall, Lando still seems much slower than VVV. The CPU is working way harder. I lose about 10% battery when doing a build (though that may be more the fault of running Grunt build for core), and running things like AMP revalidation loopback request or doing PHPUnit tests take longer to finish. Surely we must not be doing something right.

[westonruter]

Case in point for apparent slowness of Lando, when running the AMP plugin's unit tests (lando phpunit tests/test-amp-style-sanitizer.php), there are 5 that take longer than a second, some much longer:

Test Name	Duration (Seconds)
test_link_and_style_elements with data set "style_elements_with_link_elements"	5.557160
test_font_data_url_handling	5.498472
test_large_custom_css_and_rule_removal	9.634091
test_relative_background_url_handling	12.282429
test_keyframe_sanitizer with data set "style_amp_keyframes_max_overflow"	45.837876
test_css_import	6.323279

The PHP-CSS-Parser is computationally expensive, but when running these on VVV maybe only the style_amp_keyframes_max_overflow test would take just over a second. But in Lando it is more than a magnitude worse in terms of performance. Why?

[westonruter]

Aside: WordPress can be run from src again! https://make.wordpress.org/core/2018/12/24/build-tools-weve-enabled-running-wordpress-from-src-again/

[felixarntz]

@westonruter I created another PR (#5) as an augmentation of this one (using your reorg branch as the starting point) with the goal to add a bit more flexibility in how to run core in particular. Since it changes quite a few things around, I didn't want to touch this branch before having a conversation, therefore created a new reorg2.

The new PR includes all improvements you made here, plus a few more.

[westonruter]

Closing in favor of #5.