Ignore roots with too-high feature-version when creating SQL server

`feature-version.bats` contains a test: `"feature-version: older client maintains access to feature branch"` which asserts that fetching changes from a remote with a higher feature version is safe and does not disrupt other commands, provided that the remote is not pulled into a working set.

Unfortunately, the CLI migration breaks this. After running `dolt fetch` in the test, all migrated commands fail.

This is because migrated commands attempt to start a SQL server, and the SQL server attempts to load every root (which includes both working sets and remotes.)

We need some way for the server to start in this case. The easiest option is simply to ignore roots if they contain too-high feature versions and make them not available in the SQL session.

Start with feature-version.bats and run the test named "feature-version: older client maintains access to feature branch" after reproducing the dolt fetch. Trace the migrated command's SQL server startup and root loading; done means the server starts despite a remote with a higher feature version, while that root is unavailable in the SQL session and other commands continue to work.

Written by the indexing model from the issue text.