Removing legacy-migration stuff

[stuartpb]

One of the motivations for this fork is to remove legacy cruft from Beaker (like Dat support, cf. #4); right now, I'm seeing a lot of code that deals with migrating from 0.x Beaker versions in the codebase.

My thinking is, whatever users that were driving 0.x releases of Beaker have most likely run 1.1 at some point, and any users that haven't most likely weren't doing anything critical enough that they'd notice/remember their data not migrating in the new release. (And, in the vanishingly unlikely case there are, they can just go ahead and download 1.1 to do that migration before using this fork; I could include some kind of "legacy detection" prompt for this, but, again, any user in that deep a niche is most likely aware that they'd need to do something like this.)

legacy migration stuff

• [ ] all the old SQL schemas
  • since none of these have dependencies, these are harmless
• [ ] migrateBookmarksFromSqlite in app/bg/filesystem/bookmarks.js
• [ ] there's a line in app/bg/filesystem/index.js that creates the root hyperdrive for the browsing profile if the previous one had a dat: URL (but doesn't do anything with said dat)

[stuartpb]

My line here is that legacy data shouldn't cause the modern parts of the app to malfunction (ie. the line that creates the root hyperdrive if it used to be a dat isn't getting removed), just that the legacy stuff won't be recognized or function.

[stuartpb]

Ideally, though, all this kind of stuff would be handled by a migrations or legacy directory of scripts that detect if they need to run at the beginning of startup, then bring the system up to the expected current API surface - the sqlite stuff already kind of works this way