Make `bssl::Span::subspan` behave like `std::span::subspan`.

This means it will no longer clip requested sizes to what is available,
but instead `abort()` the process. In comparison, `std::span::subspan`
would throw a contract violation, whereas `absl::Span` clips.

This enables compile-time sizing of `std::span::subspan` return values
even if the input span is runtime sized.

Also, a bunch of places have been changed to perform desired clipping at
the call site; `subspan` use has previously been audited and marked in
I5d37c730fd6ea131f3b3bfafe7ea0fe690906a22.

Audited all potential new `abort()` calls with Ghidriff; found the
following two places of interest:

- https://boringssl.googlesource.com/boringssl/+/4c2a6a5467e4abea270877740b5975cac772802d/ssl/d1_both.cc#775
  uses offsets and lengths from `range` and indexes into `body` with
  them. `body` is 12 bytes less than `msg.data`, and `range` is
  initialized to precisely that size, so things should be fine.
- https://boringssl.googlesource.com/boringssl/+/4c2a6a5467e4abea270877740b5975cac772802d/ssl/tls13_enc.cc#668
  assumes `msg` is at least `full_header_len` large, and that
  `offset >= full_header_len`. In the former case it'd already be
  failing anyway; the latter case would be obvious nonsense and indicate
  a clear bug of the caller. I checked all callers, and none can cause
  this condition right now.

Update-Note: `bssl::Span::subspan` method now fails when second argument
points beyond span length. Previous `sp.subspan(pos, len)` can be
rewritten as `sp.subspan(pos, std::min(len, sp.size() - pos))` if
necessary.

Bug: 453872746
Change-Id: I68d031abc0d8d5a602d9913bcd88cde659fb1956
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/83707
Reviewed-by: David Benjamin <davidben@google.com>
Auto-Submit: Rudolf Polzer <rpolzer@google.com>
Commit-Queue: Rudolf Polzer <rpolzer@google.com>