api: document a couple panicking preconditions

This brings the API documentation for `Span::offset` and
`packed::Searcher::find_in` into consistency with `Input::span`. That
is, if you try to set offsets that are incorrect for the provided
haystack (or are pathologically invalid), then you get a panic. This
mimics how, e.g., `&slice[range]` works.

This addresses a [RUSTSEC advisory proposal] for these omissions from
the docs. The proposed advisory misses the forest for the trees: if you
go out of your way to use invalid offsets, then you're going to have a
bad time. On top of that, offsets are rarely provided as inputs from
users. That is, offsets are usually _trusted_ information, which is why
it's reasonable to establish their correctness as a precondition.

[RUSTSEC advisory proposal]: rustsec/advisory-db#2684

Author: BurntSushi

src/packed/api.rs

@@ -502,6 +502,10 @@ impl Searcher {
     /// `0`) in which it was added. The offsets in the `Match` will be relative
     /// to the start of `haystack` (and not `at`).
     ///
+    /// # Panics
+    ///
+    /// When `span` does not correspond to a valid range in `haystack`.
+    ///
     /// # Example
     ///
     /// Basic usage:

src/util/search.rs

@@ -709,9 +709,20 @@ impl Span {
 
     /// Returns a new span with `offset` added to this span's `start` and `end`
     /// values.
+    ///
+    /// # Panics
+    ///
+    /// This panics if adding `offset` to either part of this `Span` would
+    /// result in overflow.
     #[inline]
     pub fn offset(&self, offset: usize) -> Span {
-        Span { start: self.start + offset, end: self.end + offset }
+        Span {
+            start: self
+                .start
+                .checked_add(offset)
+                .expect("invalid start+offset"),
+            end: self.end.checked_add(offset).expect("invalid end+offset"),
+        }
     }
 }