Feat/fetch manifests

[Keyrxng]

Resolves #4

Why I choose to do it like this:

1. If we pull from our ubiquityos-config.yml, that's all the plugins which are active and installable (in theory as quite a few produce errors when fetching their manifest)
2. We could just pull the manifest content from each repo but not guaranteed that plugin is active.
3. I think it's better UX if we have one portal which has all the plugins ready to be installed and we can list them or carousel them or something and one-click install/optional user input on configurations.

I could just read the manifest.json directly from each repo in -marketplace instead if that's the 'official' marketplace for installable plugins.

You've always been the CSS guy between us @0x4007, I lack the finesse, maybe a task specifically for handling the huge configs and designing config customizations

QA:

If you look at the worker URL keys in localStorage they look kinda messy. We should update them to all have uniform names if possible.

[0x4007]

Might need to reopen this pull to exclude the template diff

[Keyrxng]

I pretty much abandoned my approach used in this PR but used the manifest fetching logic in #13.

I realized that it's cleaner to just parse manifests directly from the marketplace than to parse our configs for active plugins then fetch them via the pluginUrl because there shouldn't be an unstable or inactive plugin within the -marketplace repo.

If you look at the worker URL keys in localStorage they look kinda messy. We should update them to all have uniform names if possible.

Also because this proved to be a problem recently that configs contained outdated worker endpoints so fetching the manifest that way failed for more than a few.

[ubiquity-os-beta]

@Keyrxng, this task has been idle for a while. Please provide an update.