Overhaul Inheritance and Override Logic

[ekpyron]

#12615 reported a serious error in our override logic.
While #12616 fixes the issue, we realized that our strict override logic has some counterintuitive implications, namely #12616 (comment) and #12616 (comment).

So we intend to relax our override requirements to avoid cases like that.

In particular, we want to have a specification with the following property:

• Each direct base of a contract can contribute at most one base function to the override requirements of a function.

In particular consider the following situation:

interface I { function f() external; }
contract A is I { function f() external {} }
contract B is I { }
contract C is A, B {
  // no override is required here!
}
contract D is C {
  // The following *should* be valid, but currently fails and requires "override(I, A)".
  function f() external override // more specifically "override(A)"
  {
  }
}

Our current plan is to relax the override requirements, s.t. D in the example becomes valid.
However, this is breaking (since currently specifying more bases than required is an error).
So more specifically, we want to do this change while allowing additional bases (with a warning) in 0.8, while those additional bases will become an error only in 0.8.

So this issue has two parts:

• Relax the override requirements while allowing the bases that were previously required with a warning (non-breaking).
• Disallow the additional bases we warned about in the next breaking release (breaking).

[cameel]

Perhaps #13136 should be a part or this too.