This commit adds simd acceleration support to the `memmem` module. This
is added with the freshly-stabilized support from rust-lang/rust#86204.
This mostly just cribs off the generic simd support for 128-bit types
built for sse, copying bits and pieces of code here and there. Some
refactoring happened internally to help reduce duplication where
possible.

I ran some initial benchmarks with the `memmem/krate/*` regex and a
hacked up single-threaded version of criterion. Some [initial
comparisons][compare] using Wasmtime as a runtime do indeed show a lot
of improvements, but there are indeed some slowdowns as well.

[compare]: https://gist.github.com/alexcrichton/6a72e682e7b6d505ade605359fbe3f2d

PR #84

This is a long overdue benchmark of the WASM implementation that landed
in #84. I tried to do this a few months ago, but I mucked it up and
never got back around to it. (This is also why I haven't put out a new
release with the WASM implementation, since I wanted to do a sanity
benchmark run first.)

Closes #90, Closes #93

The documentation for FindIter and FindRevIter already include
this detail. However, it was not immediately clear to me from
the documentation what find_iter and rfind_iter do about
overlapping matches. This commit resolves that confusion by addiing
"non-overlapping" to the description.

Closes #95

`memmem::Finder::new(needle).into_owned().find_iter(haystack)` returns
a `FindIter` that borrows the `Finder`. That `Finder` owns a copy of
the needle.

`memmem::find_iter(haystack, needle)` returns a `FindIter` that owns a
`Finder` that borrows the needle.

There is currently no way to get a `FindIter` (or `FindRevIter`) that
owns a `Finder` that owns a copy of the needle. This prevents storing a
`FindIter` in some struct without `Box`ing the `Finder`.

This change adds just that.

Closes #99

Generating all the prefilter test cases at once caused memory usage to
spike up to ~7.1 GB. This lazy implementation sees ~100 MB peak.

More specifically, this crate always OOMs in crater due to the sandbox
limits. In fact, its test suite can hit a peak memory usage of ~7.1 GB
which as far as one can tell is a comfortable 2x greater than any other
crate in the top 1,000 by downloads.

Closes #105