[#64] implement copy paste protection

[YuriRomanowski]

Description

Problem: Currently xrefcheck is not able to detect possibly bad copy-pastes, when some links are referring the same file, but from the link name it seems that one of that links should refer other file.

Solution: Implement check, add support for related annotations for .md files, add corresponding settings to the config.

Related issue(s)

Fixes #64

✅ Checklist for your Pull Request

Ideally a PR has all of the checkmarks set.

If something in this list is irrelevant to your PR, you should still set this
checkmark indicating that you are sure it is dealt with (be that by irrelevance).

Related changes (conditional)

• Tests

  • If I added new functionality, I added tests covering it.
  • If I fixed a bug, I added a regression test to prevent the bug from
    silently reappearing again.

• Documentation

  • I checked whether I should update the docs and did so if necessary:
    • README
    • Haddock

• Public contracts

  • Any modifications of public contracts comply with the Evolution
    of Public Contracts policy.
  • I added an entry to the changelog if my changes are visible to the users
    and
  • provided a migration guide for breaking changes if possible

Stylistic guide (mandatory)

• My commits comply with the policy used in Serokell.
• My code complies with the style guide.

✓ Release Checklist

• I updated the version number in package.yaml.
• I updated the changelog and moved everything
  under the "Unreleased" section to a new section for this release version.
• (After merging) I edited the auto-release.
  • Change the tag and title using the format vX.Y.Z.
  • Write a summary of all user-facing changes.
  • Deselect the "This is a pre-release" checkbox at the bottom.
• (After merging) I updated xrefcheck-action.
• (After merging) I uploaded the package to hackage.

[Martoon-00]

This is the same what I asked @aeqz for on one of his tickets: please split this in at least two parts to keep it simple.

I'd suggest the following two parts: core, verification, tests, config update could go in one PR, and annotations handling could go into another place (separate from #238).

[Martoon-00]

And let's assume that the annotations handling PR will depend on the core PR (will have all the commits from the core PR + commits for annotations handling), so that we could have a working part of the functionality after merging the first PR.