Updates to 0.8.7, Refactors run() command

I am refactoring the run() command because it was over 140 lines long
which makes understanding it a bit hard. All tests pass. after the
refactor.
Attempting to make it more testable
Converting to a bit of nunit/FakeItEasy to allow for easier testing

In order to feel better about RoundhousE I'd like to test the migration runners.
I wasn't able to do this easy using bdd. I'm creating a project for using NUnit
and FakeItEasy to allow me to more easily test the internals and to allow for
a bit higher code coverage around crucial functionality.
The solution is now NCrunch friendly

Added links to the snk file for NCrunch to be able to build the solution, fixed
up bad project references.
Allows for testing of the migration runner

It isn't testing much yet, but it will allow me to ensure that the dry
run is working as it should.
Puts some tests around creating/dropping DB on DryRun

Now checks various scenarios with or without dryrun to ensure that the
database is not created/dropped during a dry run, but it is
created/dropped otherwise.
Adds more dry run logic around running support tasks/transactions
Dry run now prevents the versioning of the database

Prevents the versioning of the database for the dry run. Removed the Crypto
spec
Puts dry run protection around log_and_traverse_known_folders

Now prevents running the scripts found in various folders. Does not say which scripts will be run, however.
Fixing up a test to match the proper error message.
Some minor cleanup in dryrun behavior

Removed the console.readline() when mentioning the dry run. Wraps the final message about kicking the database in dry run protection. Started a test around dry run protecting the database drop feature.
Starts some tests around DatabaseMigrator

I'm noticing that the dry run needs some logging done at the level of
the DatabaseMigrator, so I'm building testing around it. This requires a
TestableDatabaseMigrator which allows me to adequately test the
internals of the class. I had to unseal the class and make the private
readonly fields into protected non-readonlys.
Dry run protections around create_or_restore_database

Put dry run protection around the creation and restoring of the
database. Code coverage on teh DefaultDAtabaseMigrator is steadily going
up.
Made DefaultDatabaseMigrator DryRun-safe

Code coverage is roughly 80%. Handles dry run configuration appropriately
and logs informative messages to the end user. Now that it is dry-run safe the
RoundhouseMigrationRunner should call more of these methods to allow for
better logging to be seen by the user.
Cleans up RoundhouseMigrationRunner tests a bit

I removed the *ncrunchsolution* files from the repository. I also used a
MakeTestableSut() function to make the tests smaller and easier to understand
MigrationRunner calls methods in the DatabaseMigrator in DryRun

Because I was able to make DatabaseMigrator DryRun-safe (meaning it won't
modify the database if Configuration.DryRun is true, I made the
RoundhouseMigrationRunner call the methods directly in the DatabaseMigrator.
This will allow for more meaningful logging to the client during DryRuns.
UI tweaks for better readability

I made some tweaks to the console text to make changes to the database more
easily identifiable. I also tried to guess if someone was trying to do a dry run
against a database that doesn't have the RoundhousE support tables created in it.
RoundhousE will give the user some information about running it agains WITHOUT
the dryrun switch.
Adds an option (--explore) that launches explorer

When the migration is complete it will open explorer.exe to your
change_drop folder. This is great for dry runs or for migration when a
database team wants to run the scripts manually.
Puts scripts in "scripts" folder, numbered order

The --simpleoutput option now puts the scripts in a folder called
"scripts" (instead of "itemsRan") and prepends a number in front of each
script in the order it would be run, i.e. 100_SelectProjects.sql.
Limitations: It only does roundhouse scripts, it doesn't do the support
scripts (like creating roundhouse tables, recording version numbers,
etc.)
Building some tests around sqlserver database