Fix latest version parsing for crates with hypens

Crates with hypens 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](huhu@4e84385#diff-dc9969d9ec58ceb09765359c0caa6852a087b462d98bb9a7e45f1ac75c79b066L12-R14) (which itself addressed [fallout](huhu@7483ba3#diff-dc9969d9ec58ceb09765359c0caa6852a087b462d98bb9a7e45f1ac75c79b066R12-R15) from `rustdoc` [changing its version output](rust-lang/rust@6a5f8b1#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 hypens](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](https://github.com/rust-lang/docs.rs/blob/dad5863093535004623df9e7d3789a11502313a5/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) I think. This is the change I have implemented.

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](rust-lang/docs.rs#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`](https://github.com/rust-lang/rust/blob/502d6aa47b4118fea1e326529e71b25a99b0d6c5/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.

extension/script/add-search-index.js

@@ -10,8 +10,8 @@
             // If we parse the crate version from url is 'latest',
             // we should reparse it from the DOM to get the correct value.
             if (crateVersion === 'latest') {
-                let versionText = document.querySelector('.nav-container a.crate-name>.title').textContent;
-                crateVersion = versionText.split('-')[1];
+                let versionText = document.querySelector('nav.sidebar .version').textContent;
+                crateVersion = versionText.split(' ')[1];
             }
             window.postMessage({
                 direction: "rust-search-extension",
@@ -81,4 +81,4 @@
         }
 
     }
-})();
+})();