Cleanup, doc update and small micro-optimizations

Hi all,

I have been familiarizing myself with clang's codebase in the past
few week ( for now Basic/ and AST/ ) and have noticed in a few places
some code that could be cleaned-up, some doc that could be updated and
some possible micro-optimizations. Some (non-exhaustive) examples:

- 1. (cleanup) in AST/CanonicalType.h

the ctor
  /// Converting constructor that permits implicit upcasting of
  /// canonical type pointers.
  template <typename U>
  CanQual(const CanQual<U> &Other,
          typename std::enable_if<std::is_base_of<T, U>::value, int>::type = 0);

has no definition that I could find and so clearly nobody is using it.
It could be therefore be removed.

- 2. (doc update) in AST/CanonicalType.h

the doc

  /// This arrow operator is used when CanProxyAdaptor has been specialized
  /// for the given type T. In that case, we reference members of the
  /// CanProxyAdaptor specialization. Otherwise, this operator will be hidden
  /// by the arrow operator in the primary CanProxyAdaptor template.
  const CanProxyAdaptor<T> *operator->() const {
    return static_cast<const CanProxyAdaptor<T> *>(this);

references an operator-> in the primary CanProxyAdaptor template, but
this class template is empty.

- 3. (micro-opt) in AST/CXXInheritance.{h,cpp}

by changing a few containers and reordering the order of the members in CXXBasePaths
I get about 0.1%-0.15% performance improvement when doing an fsyntax-only on all
of Boost's headers. (with custom instrumentation because it is well below the noise otherwise)


- 1. Should I send patches for changes in these 3 categories ?
None of these change is a big deal in itself but since I am reading the code anyway
I might as well fix some of these little things.

Regarding 3. (micro-opt) On one hand obviously improving the code at a higher
level has the potential to bring much greater improvements but on the other hand
these little modifications are easy and adds up.

- 2. If the answer to question 1. is yes then who should I put as reviewer ?
According to CODE_OWNERS.txt I should put Richard Smith but maybe someone is
better placed to review these kind of changes.


Bruno Ricci