* Add migrations.js
* Migrate crate manager to storage
* Add common js files to base template
* Migrate statistics, crates, index pages
* Don't re-migrate.
* Fix statistics and history storage
* Migrate all settings item to async getter and setter
* Migrate main.js to chrome.storage api
* Migrate settings, import/export pages to chrome.storage api
* Fix main.js
* Add comments to setttings.js
Crates with hyphens have their version extracted from the DOM (when
viewing the latest version of a crate and adding it to the extension's
index) incorrectly.
This in turn causes the extension to produce invalid docs.rs links.
----
[This snippet](4e84385e83 (diff-dc9969d9ec58ceb09765359c0caa6852a087b462d98bb9a7e45f1ac75c79b066L12-R14))
(which itself addressed[fallout](7483ba377d (diff-dc9969d9ec58ceb09765359c0caa6852a087b462d98bb9a7e45f1ac75c79b066R12-R15))
from `rustdoc` [changing its version output](6a5f8b1aef (diff-40a0eb025da61717b3b765ceb7fab21d91af3012360e90b9f46e15a4047946faL1768-L1776)))
is the problematic bit.
Updating the logic linked above to take the _last_ element after
splitting on `-` instead of the second fixes this case but I think this
leaves _other_ edge cases unhandled.
For example, `cargo` and friends allow for [pre-release versions which
are allowed to have hyphens](https://semver.org/#spec-item-9) (i.e.
`0.0.1-my-extremely-unstable-release`). While it's unlikely that the
docs.rs "latest" link for a crate will redirect to one of these, it is
still possible – `docsrs` will [search stable, unyanked releases _first_
but *will* fall back to pre-releases](dad5863093/src/web/mod.rs (L341-L368)).
The [`wasi` crate](https://docs.rs/wasi/latest/wasi/) is one such
example of this (no "stable" releases as of this writing, pre-release
version has a hypen in it: `0.11.0+wasi-snapshot-preview1`).
Reverting to the previous method (grabbing the version from the sidebar)
and changing the query to `'nav.sidebar .version'` is general enough to
support pages generated before and after the `rustdoc` version change
without being _too_ general (and potentially picking up things in
user-added HTML snippets). This is the change this commit implements.
The downside to this approach is that it doesn't work on `rustdoc`
output that predates the addition of the version in the sidebar; since
docs.rs [doesn't rebuild docs for older releases](https://github.com/rust-lang/docs.rs/issues/464)
this can be a real concern for older stable crates that haven't had a
release in a while.
---
Another approach is to snoop through some of the relative links on the
page and to extract the version from the relative URLs there. There
doesn't seem to be an obvious thing in the DOM to go after and we're
definitely still susceptible to changes in `rustdoc` this way; I'm not
sure if this is worth doing.
Yet another option is to pick an approach based on the `rustdoc` version
in [`rustdoc-vars`](502d6aa47b/src/librustdoc/html/templates/page.html (L147))
(i.e. `document.querySelector("#rustdoc-vars").getAttribute("data-rustdoc-version")`).
This could help a little but it's worth noting that it itself is a
relatively recent addition to the `rustdoc` HTML output, I think.
