Use saturating arithmetic to avoid usize overflow panics (#1066, #1067, #1068)

[patrickwehbe]

Three Itertools methods can panic with an overflow in debug builds when
given very large inputs. Each one does an unchecked + 1 or * 2 on a
usize that can already be near the maximum. This switches them to
saturating arithmetic.

• k_smallest_relaxed (issue Bug in k_smallest_relaxed? #1066): it allocates room for 2 * k items,
  which overflows once k is greater than usize::MAX / 2. Now it uses
  saturating_mul, so a huge k saturates to usize::MAX and the whole
  iterator is collected, the same result you already get from k_smallest.
• peek_nth and peek_nth_mut (issue Peeking usize::MAX with peek_nth #1067): both compute n + 1, which
  overflows when n == usize::MAX. Now they use saturating_add, so
  peeking that far just returns None, which is what peeking past the end
  already does.
• InterleaveShortest::size_hint (issue interleave_shortest's size_hint panics with large iterators. #1068): the lower bound is computed
  as combined_lower + 1, which overflows when combined_lower is
  usize::MAX. Now it uses saturating_add. The upper-bound branch a few
  lines down already uses checked_add, so this just brings the two into
  line.

I added a regression test for each in tests/test_std.rs that calls the
affected method with usize::MAX-ish input and checks it returns instead of
panicking.

The reporter (@Takashiidobe) suggested the saturating approach in #1066;
the same idea applies cleanly to all three.

Fixes #1066
Fixes #1067
Fixes #1068