Fixed dependency order issues with data upgrade script.

I had scripted updates for all tables, in dependency order, then scripted inserts for all tables, in dependency order. However, that did not work when inserting a new row in table A and updating an existing row in table B to refer to the new row in table A. With this approach the update to table B was scripted before the insert to table A (all updates were scripted before all inserts). This would fail due to a foreign key violation.

Now we loop through the tables in dependency order and for each table script updates then inserts. With this approach the insert to table A is scripted before the update to table B.

To verify that this approach should always work, I made the equivalent of a truth table, with values I, U, and D (insert, update, delete) instead of T and F (true and false) for tables A and B and determined which table needed to be first.
Skip generating SchemaFinal.sql if there are no other upgrade scripts.

This is a small step to optimize the process when there are no database changes.
Added ability to sync a target database.

This is similar to generating an upgrade script except the intent is not to generate a script that will later be used to update a production database. Instead, the purpose is to sync a target database now.

In sync mode the target database may have lots of data that is not part of the database creating scripts (it is not "static" data) is is therefore not in the source database. Using the upgrade process this data would be deleted. But using sync this data will be preserved. Sppecifically, tables have rows in the target but are empty in the source will not be deleted.

Other changes:
 * Added options to run without prompting (-f and -n) so the tool could be used by an automation script with no user interaction.
 * Added DataUpgradeReport.xml and show tables with deletes in console output.