Comment 1 for bug 1825896

Summarizing some discussion from the hackfest:

 - We do not believe that there is reason to have a setting to enable/disable using Hatch to store workstation registrations. If Hatch is available, store workstation registrations there, if not, store in local settings.

 - As a migration path, once this code is in place it should attempt to retrieve the list of workstation registrations from Local Storage and migrate them to Hatch, then remove them from Local Storage.

 - This migration process may run multiple times in the case of multiple local instances of Local Storage (browser profiles or multiple OS users using the same Hatch storage dir), and should merge workstation registrations, not replace them. The first "default" workstation should remain default despite any subsequent local settings migrations potentially having a different default workstation.

 - As part of this, change the default data directory (data.directory in the hatch.properties file) on Windows to a shared machine-wide directory (an .evergreen directory in %ProgramData% / $Env:ProgramData / C:\ProgramData being the most likely value for data.directory). This would be implemented by the Hatch Windows installer putting in place a default hatch.properties file or performing a string replace on that file. It might be an install-time prompt or command line argument to override this new behavior.

- Similar (but different) to the migration strategy for workstation registrations, when faced with an empty/new data.directory that isn't the default user.home + ".evergreen" directory, Hatch would look for that (formerly default) directory and migrate settings from there to the new directory. Unlike the migration strategy for workstation registrations above, this would only migrate the first encountered directory to the new/empty directory.