'bzr branch --stacked' makes empty repo then builds a working tree with inefficient fetching

When doing a 'bzr branch --stacked' from a smart server that builds a working tree (the default scenario, i.e. --no-tree is not used, and not in a shared repo with working trees disabled), then it creates an empty repository and then starts the build-tree logic. This slowly walks the inventory and fetches texts individually, and doesn't cache any of that data in the local repo when done.

It would take far fewer network roundtrips (especially HPSS VFS ones), and greatly reduce bytes transferred, to instead ask the remote server to stream just the revision+inventory+texts (and associated signatures and chk_bytes) necessary to construct the tree for the one revision.

I have a rough branch that does this by:
 * define a new fetch spec for that
 * in BzrDir.sprout if we have a new stacked repository and are building a working tree, use that fetch spec
 * extend the StreamSource to understand that fetch spec.

This also has the benefit that the data that is being fetched anyway is saved in the local repo to benefit future operations (as well as fetching that data much much more effiiciently).