Remove saturating arith from state_processing (#1644)

## Issue Addressed

Resolves #1100

## Proposed Changes

* Implement the `SafeArith` trait for `Slot` and `Epoch`, so that methods like `safe_add` become available.
* Tweak the `SafeArith` trait to allow a different `Rhs` type (analagous to `std::ops::Add`, etc).
* Add a `legacy-arith` feature to `types` and `state_processing` that conditionally enables implementations of
  the `std` ops with saturating semantics.
* Check compilation of `types` and `state_processing` _without_ `legacy-arith` on CI,
  thus guaranteeing that they only use the `SafeArith` primitives 🎉

## Additional Info

The `legacy-arith` feature gets turned on by all higher-level crates that depend on `state_processing` or `types`, thus allowing the beacon chain, networking, and other components to continue to rely on the availability of ops like `+`, `-`, `*`, etc.

**This is a consensus-breaking change**, but brings us in line with the spec, and our incompatibilities shouldn't have been reachable with any valid configuration of Eth2 parameters.

consensus/state_processing/Cargo.toml

@@ -27,14 +27,16 @@ log = "0.4.8"
 safe_arith = { path = "../safe_arith" }
 tree_hash = "0.1.0"
 tree_hash_derive = "0.2.0"
-types = { path = "../types" }
+types = { path = "../types", default-features = false }
 rayon = "1.3.0"
 eth2_hashing = "0.1.0"
 int_to_bytes = { path = "../int_to_bytes" }
 arbitrary = { version = "0.4.4", features = ["derive"], optional = true }
 
 [features]
+default = ["legacy-arith"]
 fake_crypto = ["bls/fake_crypto"]
+legacy-arith = ["types/legacy-arith"]
 arbitrary-fuzz = [
   "arbitrary",
   "types/arbitrary-fuzz",