SI-7870 Detect default getter clashes in constructors

Default getters for constructors live in the companion module.
These eluded the check for clashes in default getter names due
to overloading, which aims to give a more user friendly error
than "double definition: meth$default$1".

This commit checks for default getters in the companion module,
in addition to those in the template itself.
SI-7876 Scaladoc crasher due to regression in isFunctionType.

`isFunctionType` and `isTupleType` started returing true for
type constructors as of aeb73314. This led to a crash in type
printing in ScalaDoc (specfically, in ModelFactoryTypeSupport.scala)

This commit:
  - fixes those methods by guarding with !isHigherKinded
  - unit tests said methods
  - tests the reported crasher with a ScalaDoc test.
SI-7876 Less dealiasing in Scaladoc's type printing.

Scaladoc renders tuple and function types with the syntactic sugar.

To do so, it was using `isFunctionType` and `isTupleType`. Internally,
these methods dealias, so one can't simply take the type arguments
from the given type to get the element types of the tuple.

In ac96200c92, a Scaladoc crasher in this area was resolved by
normalizing a type before extracting Tuple type arguments.

Similar code already existed in the handling of FunctionTypes.

This commit goes in the opposite direction, and instead queries
the `direct` versions of those methods, which do not perform
dealiasing.

Conseqeuently, the type aliases that appear in the source code
signatures for members will be rendered as such in Scaladoc.
Which seems like an improvement.
Merge pull request #2990 from retronym/ticket/7876

Scaladoc regression with Function / Tuple type constructors
Merge pull request #2979 from retronym/ticket/7870

SI-7870 Detect default getter clashes in constructors
SI-3971 error message carat mispoints at curried methods.

I found it to be a general palliative to unwrap applies when
reporting errors. Point at the thing being applied, not at the
opening paren of a possibly distant argument list. This might
be slightly less accurate in a few cases, but it is vastly less
inaccurate in most cases, so I think it is an easy victory for
the forces of clarity.

Thanks to retronym for figuring out why issuing a better
error message broke the compiler on non-erroneous compile runs.
The changes to "treesInResult" are the consequence.