Using more intermediate VRTs in higher-level tools

[sgillies]

For example, gdal_translate uses a VRT under the hood to gather changes and options and then relies on GDALCreateCopy to materialize those changes and produce an output file: https://github.com/OSGeo/gdal/blob/master/apps/gdal_translate_lib.cpp#L2511.

Rasterio's merge tool could similarly take advantage of an internal VRT. Our existing merge tool produces very large numpy arrays as its only possible output. An example of the direction we might take is shown in #2699.

Rasterio stack CLI program could also use a VRT. Stacking by itself wouldn't need to use a lot of resources, it would only be when materializing virtual stacks to a file that the deferred work would be done.

And of course, Rasterio's convert CLI program could use a VRT in the same way gdal_translate does.

There's no immediate action here. I want to show that #2699 isn't entirely out of the blue and is part of a theme I've been thinking about for a while: Rasterio making virtual datasets using Python XML libs and GDAL reading those datasets.

[sgillies]

Removing from the 1.4.0 milestone, which is already very large, in order to get 1.4.0 out sooner.