store FALCON_DATASET (and other env vars) so they can't get out of sync

The failure mode I ran into is that I tore down an a4x2 deployment, then started a new one that I expected to be a clean slate, but at least on g0 it had all of the state from the previous run's internal zpools. I don't know for sure what happened. But I normally set FALCON_DATASET when using a4x2 and I suspect that I neglected to set FALCON_DATASET for this invocation of a4x2 destroy and it tried to destroy the wrong datasets. It would be nice the tool recorded the locations of these datasets (like it does a lot of the other configuration) rather than relying on the user to consistently set it each time the command is run.

I'm not sure if this is also the cause of #67.

Start by tracing the a4x2 destroy invocation and how FALCON_DATASET and other environment variables are currently read, then inspect the existing configuration-recording behavior mentioned in the issue. Clarify which dataset locations must be persisted and how a new deployment should distinguish them from a previous run. Done means destroy uses the recorded locations rather than relying on each invocation's environment variables, with the suspected stale-state scenario covered.