Fix 21538,20904: Correct implicitConvTo order for delegate parameters in Type.covariant

[MoonlightSentinel]

The ordering was inversed when compared to function pointers. That caused
the check to accept e.g. less restrictive attributes for callbacks.

Also changed the equality checks for TypeFuntion and TypeDelegate
to equals because == didn't call the former and hence caused problems
for duplicate instances.

---

Preliminary check whether this affects projects on BuildKite as this breaks a test case in runnable/xtest46.d (which is an accept-invalid when using delegate parameters and already rejected for function pointers).

The test case in runnable/xtest46.d was not found in any project on Buildkite

[dlang-bot]

Thanks for your pull request and interest in making D better, @MoonlightSentinel! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Auto-close	Bugzilla	Severity	Description
✓	20904	major	dip1000 implicit conversion delegates error
✓	21538	regression	Overriding with more attributes on delegate parameter is allowed

⚠️⚠️⚠️ Warnings ⚠️⚠️⚠️

• Regression or critical bug fixes should always target the stable branch. Learn more about rebasing to stable or the D release process.

To target stable perform these two steps:

1. Rebase your branch to upstream/stable:

git rebase --onto upstream/stable upstream/master

2. Change the base branch of your PR to stable

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + dmd#13267"

[thewilsonator]

Should this target stable?

[PetarKirov]

Should this target stable?

It can't without dropping the unit tests, since it builds on top of: #13238, which was already merged in master.

[MoonlightSentinel]

Should this target stable?

Probably

It can't without dropping the unit tests, since it builds on top of: #13238, which was already merged in master.

Could also cherry-pick the commit in this PR

[PetarKirov]

Even though this a type system bug fix, it's also technically a breaking change, so I suggest master to be on the safe side.

[ibuclaw]

The test case in runnable/xtest46.d was not found in any project on Buildkite

However it was found in industry codebases.

Possibly caused a regression. https://issues.dlang.org/show_bug.cgi?id=23274

Though it should be thought carefully about whether the code broken in xtest46.d was indeed wrong in the first place.

[CyberShadow]

This pull request introduced a regression:
https://issues.dlang.org/show_bug.cgi?id=23956

Possibly the same issue as the one above.