Dependency selection is inconsistent across commands

Description

Currently, various bst commands accept the option -d/--deps to select additional dependencies of a specified element. In most cases, the option is treated as a PipelineSelection and passed to a Stream method.

However, the actual values that are accepted by the command varies:

Command	none	all	run	build	plan
show	X	X	X	X	X
source fetch	X	X			X
source track	X	X
source checkout	X	X	X	X
artifact checkout	X		X	X
artifact pull	X	X
artifact push	X	X
build (effective*)		X			X

* The current behaviour supported by the command, despite it not accepting --deps. See #1078 (closed).

Further, PipelineSelection.PLAN seems to arbitrarily be based on the ALL selection. The current behaviour of Pipeline#get_selection(el, PipelineSelection.PLAN) is to choose the union of:

• the runtime dependency subtree of el
• the build dependency subtree of el, pruned at any cached elements

The fact that the runtime deps are included seems arbitrary to me; for example, a user may wish to only fetch the sources of uncached build dependencies, but cannot with the current behaviour.

Proposed changes

1. Alter all relevant commands to accept --deps followed by a choice of Scope: all, build, run, or none. (The artifact commands will only be able to meaningfully use these after work is done towards #1103 (closed).)
2. Depending on the most sensible default behaviour, add a new option to each of such commands which specifies whether or not to prune cached elements from the constructed build dependency tree. For example, this might be called bst build --rebuild (to not prune), or bst show -d all --prune-built (to prune).

To implement this it might make sense to remove PipelineSelection entirely and replace it with an extra boolean argument Element.dependencies which describes whether to prune... if this is indeed possible.

I would love to hear your opinions on this issue; I know it's low-priority but I think it would make the UI clearer.