Address clippy lints, panic in ssz_derive on overflow (#1714)

## Issue Addressed

NA

## Proposed Changes

- Panic or return error if we overflow `usize` in SSZ decoding/encoding derive macros.
  - I claim that the panics can only be triggered by a faulty type definition in lighthouse, they cannot be triggered externally on a validly defined struct.
- Use `Ordering` instead of some `if` statements, as demanded by clippy.
- Remove some old clippy `allow` that seem to no longer be required.
- Add comments to interesting clippy statements that we're going to continue to ignore.
- Create #1713

## Additional Info

NA

consensus/cached_tree_hash/src/cache_arena.rs

@@ -1,6 +1,7 @@
 use crate::SmallVec8;
 use ssz::{Decode, Encode};
 use ssz_derive::{Decode, Encode};
+use std::cmp::Ordering;
 use std::marker::PhantomData;
 use std::ops::Range;
 
@@ -89,7 +90,6 @@ impl<T: Encode + Decode> CacheArena<T> {
     /// To reiterate, the given `range` should be relative to the given `alloc_id`, not
     /// `self.backing`. E.g., if the allocation has an offset of `20` and the range is `0..1`, then
     /// the splice will translate to `self.backing[20..21]`.
-    #[allow(clippy::comparison_chain)]
     fn splice_forgetful<I: IntoIterator<Item = T>>(
         &mut self,
         alloc_id: usize,
@@ -113,10 +113,10 @@ impl<T: Encode + Decode> CacheArena<T> {
 
         self.backing.splice(start..end, replace_with);
 
-        if prev_len < self.backing.len() {
-            self.grow(alloc_id, self.backing.len() - prev_len)?;
-        } else if prev_len > self.backing.len() {
-            self.shrink(alloc_id, prev_len - self.backing.len())?;
+        match prev_len.cmp(&self.backing.len()) {
+            Ordering::Greater => self.shrink(alloc_id, prev_len - self.backing.len())?,
+            Ordering::Less => self.grow(alloc_id, self.backing.len() - prev_len)?,
+            Ordering::Equal => {}
         }
 
         Ok(())