Fix docstring search by signatures revisited

[projekter]

This is an extension of #53824 (therefore also fixing #52669), where details on the issue can be found (and, related to this, a different area where the issue shows, namely when you try to include documentation for a particular method of a function, which is similarly impossible when type parameters are involved). The fix proposed there had two drawbacks:

• with it, it is no longer possible to discriminate between two constructor functions that differ only in the type parameters. This is remedied with this PR by adding the parameters of the constructor as a unique type to the front of the method signature.
• with it, constructors must specify type parameters explicitly. The previous behavior is restored with this PR, which allows to have the type parameters unspecified. However, I completely agree with @matthias314's analysis that in this way, it is impossible to make the distinction between existing types and parametric types (which cannot be done well during macro deconstruction). This is also an issue in the code currently in Base; any type parameter will always be seen as parametric. For this reason, I'd rather see this whole behavior disappear; in the end, you cannot write Julia code like this. Removing the if isempty would prevent such a usage. A kind of middle ground would be to allow the current behavior, but only if the type is constrained (because this would not be possible for existing types).

[matthias314]

[I'm moving the discussion out of the code review because it has a wider scope]

In my opinion, we should not allow the syntax f{T}(x::T) for docstrings if f is a function (as opposed to a constructor). For constructors, I also find it bad syntax because it cannot distinguish between actual types and type parameters. If T is a parameter, then one should write f{T}(x::T) where T. However, the currently allowed syntax might be so widespread in the existing documentation that it might be better not to change it. After all, replacing a type parameter by an actual type should not happen often. I still think that it would be helpful to run nanosoldier (or whatever tool is appropriate) over a large collection of packages to see how much would break with disallowing this syntax.