Add ability to connect to genark and UCSC browsers to jbrowse desktop

[cmdcolin]

Fixes #4927

This PR tries to add a 'favorites' system to avoid 'overload' by only allowing the user to only display a smaller set of 'favorites tracks'

I considered getting rid of the 'quickstart' system, which lets users convert an existing session into something they can clone later on, but ended up keeping it

As a potential add-on, could imagine a very intepid user of jbrowse-desktop would like to connect to a entirely custom repository which this PR isn't generalizable enough to solve (yet)

[cmdcolin]

some particular technical notes of this

• we are hosting a subset of the UCSC files on our jbrowse.org server. currently that is 85Gigabytes but I envision it could expand. that could incur an ongoing amazon s3 cost. but that is currently smaller than a single BAM file...most of the files in our UCSC clones still point at static files on UCSC
• After deploying this type of solution there is a commitment to the file structure because moving things around would create issues for clients. The current deployment is in s3://jbrowse.org/ucsc, which gives us links like https://jbrowse,org/ucsc/hg19/config.json. There is also s3://jbrowse.org/hubs/genark/ with many genark configs in there. Our ingestion routines give us maximum control versus relying explicitly on ucsc hub translation layer to be built entirely into the app

[cmdcolin]

even though this PR is conceptually pretty ok for single species browsers, we may need to think about what the implications are for cross species browsers

Currently, for viewing a synteny track, e.g. a liftover alignment between species, we need both assemblies loaded in the config. there is not real concept of lazy loading an assembly and it's tracks.

Therefore, the only way to effectively look at comparative data in the browser, is to use a 'mega config' that is a combination of all the browsers

This can be done for UCSC, but the config.json is 30 megabytes (so far...)

This points to a potential need for lazy loading configs, or connections that defer loading of tracks, or some other type system.

As much as I'd like to merge this PR, until this is figured out, we may need to defer this PR...maybe