Separation of migration engine from rest of framework

A bit of background on this PR.  My goal is to use FluentMigrator as a means of SQL generation only.  My environment contains client DBAs, in-house DBAs and developers.  The project can be deployed for any of a number of databases, but the client DBAs or in-house DBAs may have specific scripts they want to attach for tuning, security, etc. that are specific to the environment.  

While FluentMigrator has the capabilities to perform these actions, asking the DBAs to use development tools to generate the statements they're already writing by hand is a non-starter.  My goal with these commits is to allow FluentMigrator to generate SQL files without a connection to the database, since in a client-deployed scenario I do not have access to their environment and it seems a bit silly to recreate their database only to get key bits of information out of the VersionInfo table.

Once the SQL files are generated they can be combined with whatever SQL files the DBAs would like to attach and can be applied either manually (yuck) or through the RoundhousE migrations engine (https://github.com/chucknorris/roundhouse).  

Please note that the effort I've started I do not consider to be complete at this time.  I've performed the following tasks:

1. Added --startingVersion/--sv flags to the console runner to allow migration to proceed without querying VersionInfo.
2. Added --suppressVersionInfo flag to the console runner to suppress VersionInfo migration expressions from being added to the output.
3. Added lazy evaluation of connection strings and database providers to avoid unnecessary database connections and assembly dependencies.  I did this using Func<T> rather than Lazy<T> since the project is based on the 3.5 framework.  With this set of changes it is possible to use the console runner with migrate.exe, the runner dll and the core dll only, assuming you output SQL to a file and specify the starting version.

The following still needs to be done.  I'm willing to help out with most of these tasks over time:

1. Revisit item 3 above.  I took a bit of a shortcut and noticed late in the game that the signature for ConnectionString is exposed directly to the MigrationBase class, so it's a breaking change for any user of the framework.  I'm not entirely sure how much that property is being used by users of the framework (IMHO, it's an abstraction leak - the framework does a great job and users shouldn't really need the connection string).
2. Add unit tests.
3. Verify the integration tests to make sure I didn't break anything.
4. Verify rollback functionality.  I'm pretty sure there are holes in what I've done around rollbacks.
5. Revisit the separation of SQL Generation and SQL Execution in the runners.  This seems tied pretty tightly today.