nuke missed flyway items when moving flyway folder
my bad, Toad actually doesn't trip a false positive on database name
Having the ability to backup/restore databases succinctly can enable many workflows to help confidently and quickly create database migrations

In this commit I added the ability to easily backup dev and prod and to easily restore to dev to enable the following workflow
- Backup dev (backup_dev), backs up to employees_dev.sql.gz
- Change dev willy nilly (if you like your sql tools you can keep them), write tests (perhaps drive your changes with tests)
- Settle on a design
- Reverse engineer your changes from last hour or two, not a big deal to do
- Generate change script and put into sql/VX__description.sql (create the migration sql file for flyway), see workflow below to generate change script
- Backup changed dev database (backup_changed_dev), this is just a safety net if you fail to reverse engineer your changes, backs up to employees_changed_dev.sql.gz
- Restore dev from before making your changes (restore_dev), restores from employees_dev.sql.gz
- flyway_dev migrate (will apply your proposed migration script)
- review things, run tests, see if there are issues
- if there are issues, restore your changed database if you want (restore_dev employees_changed_dev.sql.gz)

This workflow might help create the migration script
- Backup dev, restore it to dev_compare (clone_dev_to_dev_compare uses employees_dev_to_dev_compare.sql.gz)
- Make changes to dev as above
- When building migration script, run it against dev_compare, restore dev_compare from dev backup at any point to wipe the slate in the compare db (restore_dev_compare employees_dev_to_dev_compare.sql.gz)
- Can diff dev / dev_compare to review if your migration script synchronizes schemas/data ok (use any tool you like here)
- Follow above workflow to do one last test of your migration in your dev db so you can run tests and make sure it is changed the same way others will apply your changes.