moving expansions to its own test file so as to add more
add PID expansion to shell directives

this is necessary for using `$$` in shell directives
-	so that `$$` in a shell directive is the PID of the `vc` instance
-	otherwise, it would be the PID of the shell used to invoke the directive
-	and, since each shell directive gets its own shell, each PID would be different
-	and, since the main purpose for PIDs is in naming temp files, they really all need to be the same
new action directive: = for nested commands

nested commands are better than calling `vc` in a shell directive for 3 reasons:
-	they work even if vc is not in the path (e.g. it was invoked from an alias)
-	they don't reload vc from scratch and therefore should run faster
-	they will persist certain switches, like -p, -x, and -i
this last one if the most important, IMHO
-	so, in --pretend mode, a nested command expands to show what things it would execute
-	or, in --interactive mode, you can confirm the individual steps of the nested command
I've also hacked it so that a failure from a nested command will still report remaining lines from both commands
-	(i.e. both the outer command and the inner, nested one)
-	it's a bit clumsy right now, in that it repeats the "remaining commands that would have been run" bit
-	and I don't know how well this will work for --continue, whenever I get around to implementing that
but it works for now, and I'm pretty happy with it
fix bug where custom command blow up on confirmations

I had to make validate_args an augment/inner method to make this work properly
the problem is there wasn't any other good way to have something always done before execution
-	this is because, while internal commands augment execute(), CustomCommand overrides it
-	my original thought was to use a before modifier
-	but apparently modifiers aren't inherited by subclasses :-/
-	(or, to be more precise, I think that overriding a method "clears" all its modifiers, from what I can tell)
-	(so, if you _don't_ override the method, you get the modifiers, but if you _do_, you don't <sigh>)
so this way I can add the thing I need into validate_args and have all clients augment it instead of overriding it
the thing I need, as it happened was the undef of @ARGV
without that, IO::Prompter freaks out
and, since I was doing it in execute() and CustomCommand was overriding execute(), it wasn't working for custom commands
this also gives me a place to any other stuff that might need to be done, in the future, one day, or ... whatever
added a --debug switch (undocumented)

helps with bizarre crashes that the program thinks are just directive failures
plus this gives me a place to add more cool debugging stuff later
(assuming I can think of some)
fixed some output problems

primarily, I made `> %status` work
-	this should have worked all along anyway
-	plus it makes `%status` not need to work any more, which allows me to remove a special case in the code
-	and removes an extra "type" of action directive
I also made --(echo|pretend|interactive) work a bit nicer with saying multi-line strings
try to concistencize expansions

adding info expansions and env expansions to a couple of places that should have had them
also refactored env expansion to its own method, for better consistency
took env expansion out of custom_message, because that wasn't the right place for it
made the order of expansions consistent:
-	first, env expansion (if appropriate)
-	next, info expansion (pretty much always appropriate)
-	next, PID expansion (only done for shell directives)
-	finally, color expansion (if appropriate)
updating README to reflect the fact that a config is now generated for you on first run