Maintenance: Consistent use of C++11 "override" specifier (#1224)

Maintenance: Consistent use of C++11 "override" specifier (#1224)

Start following CppCoreGuidelines recommendation C.128: Virtual
functions should specify exactly one of virtual, override, or final.

Used clang-tidy modernize-use-override check to mark overridden methods.
Clang-tidy uses clang AST, so we can only modernize code that clang can
see, but we can enable enough ./configure options for clang to reach
most (possibly all) relevant classes in a single build.

Manual gradual conversion of modified (for other reasons) method
declarations is impractical because some compilers complain when a class
uses an inconsistent _mix_ of virtual and override declarations:

    warning: 'toCbdata' overrides a member function but is not marked
    'override' [-Winconsistent-missing-override]

### cbdata changes

The following manual changes avoid -Winconsistent-missing-override
warnings. Doing these separately, either before or after applying
modernize-use-override, would trigger those warnings.

* Replaced CbdataParent-CBDATA_CLASS with CbdataParent-CBDATA_CHILD
  class inheritance sequences. This fix does not really change anything
  except for making toCbdata() specifiers consistent.

* Replaced CbdataParent-CBDATA_CLASS-CBDATA_CHILD with
  CbdataParent-CBDATA_INTERMEDIATE-CBDATA_CHILD class inheritance
  sequences. This fix removes unused new/delete operators in
  intermediate classes (and associated unused static memory pools) and
  makes toCbdata() specifiers consistent. This fix was difficult to get
  right because of the old design problem discussed below.

While working on the second bullet changes, we first tried to simply
drop the intermediate CBDATA_CLASS sequence element because it should
never be needed/used in class hierarchies ending with CBDATA_CHILD.
Fortunately, CI tests discovered that dropping CBDATA_CLASS converts an
old design problem into runtime bugs: Those intermediate class
constructors (e.g., Mgr::StoreToCommWriter) actually call toCbdata()
when creating connection closure callbacks and such!

During intermediate constructor execution, the class virtual table does
not yet point to toCbdata() defined by CBDATA_CHILD. If we simply remove
CBDATA_CLASS, then, during that intermediate constructor execution, the
virtual table would still point to pure CbdataParent::toCbdata(). Those
intermediate constructors would then crash Squid:

    FATAL: Dying from an exception handling failure;
    exception: [no active exception]

    in OnTerminate () at main.cc:1310
    in std::terminate() () from libstdc++.so.6
    in __cxa_pure_virtual () from libstdc++.so.6
    in CbcPointer<Mgr::StoreToCommWriter>::CbcPointer at CbcPointer.h:94
    in Mgr::StoreToCommWriter::StoreToCommWriter at ...oCommWriter.cc:29

We now use lighter CBDATA_INTERMEDIATE() instead of intermediate
CBDATA_CLASS. The resulting code is as risky as it used to be, but at
least we are marking this (old) design problem (in some cases).

We rejected the idea of defining CbdataParent::toCbdata() instead. It
would work fine for linear class inheritance where "this" does not
change -- in those simple class hierarchies, we do not need toCbdata()!
However, such a change would make any constructor-time bugs in multiple
inheritance hierarchies much more difficult to find because the faulty
constructor will work instead of triggering the above FATAL error. The
crashes would happen later, when wrong cbdata pointer is used. While
CBDATA_INTERMEDIATE() cannot fix this design problem, it does not make
it _worse_, so we prefer that solution.