vpython: Add VirtualEnv creation package.

vpython/venv/test_data/README.md

+## Test Data?
+
+This test data directory is used by VirtualEnv tests to simulate a full
+environment setup.
+
+A fake CIPD client in `venv_test.go` will load this, treating each intermediate
+file as a CIPD archive:
+
+* If the file is a directory, it will be recursively copied when installed.
+* If the file is a ZIP archive (ends with `.zip`), it will be unzipped when
+  installed.
+
+It sucks that we're committing some binaries to the repository, but it's the
+best option to have a cross-platform self-contained unit test that really
+exercises the interesting parts of the setup. The `virtualenv` binary is the
+only large binary, though. It's downloaded directly from the Internet.

[iannucci, 2017/02/23 00:54:21]

It looks like it's committed to the repo as part of this cl? TBH I'd rather just
put the test artifacts in a cipd package and ensure them as part of the test
(and have a sh script to generate new ones). It should be extremely unlikely to
fail.

This is what we're probably going to move towards for large binary testing
dependencies in chromium too, so we should get ahead of the curve.

[dnj, 2017/02/23 20:38:49]

ATM, this package is not bound to CIPD or our infrastructure. Adding a CIPD
package or permanent hosting path would definitely undermine that.

"Git LFS" would probably be appropriate, but I don't think we want to use that
here, nor will "gclient" tolerate it.

The total file size is <2MB, so it's not *awful*. WDYT?

+
+The other binaries are wheels, generated from source that is also checked into
+the `test_data` directory. These wheels have equivalent `.src` components that
+were used to generate them.
+
+To build a wheel from source, `cd` into a source directory and run:
+
+    $ python setup.py bdist_wheel
+
+The wheel will be created in `/dist/`.
+
+However, note that it is unlikely any of the wheels will actually need to be
+regenerated, since they are simple artifacts.