Fix parsing AbiTag for development compilers

[TeofilC]

When using a development compiler the compilerId isn't a prefix of the Project Unit Id. This led to a failure to parse the AbiTag.

We extend the parsing logic to handle these cases by only removing the common prefix and then any leading '-'s.

Resolves #10170

Manual QA notes

To test this try using cabal-install with a development version of the compiler, and check that the AbiTag is actually parsed. (I did this with traces locally)

---

Include the following checklist in your PR:

• Patches conform to the coding conventions.
• Any changes that could be relevant to users have been recorded in the changelog.
  • Is the change significant? If so, remember to add significance: significant in the changelog file.
• The documentation has been updated, if necessary.
• Manual QA notes have been included.
• Tests have been added. (Ask for help if you don’t know how to write them! Ask for an exemption if tests are too complex for too little coverage!)

[geekosaur]

There's a little part of my hindbrain that thinks stripCommon should be in a where unless it's going to be used somewhere else as well, in which case it should be moved somewhere common.

[TeofilC]

I get you. I would be happy to move it somewhere else if you have a suitable location in mind. I agree that it feels like more of a general utility

[geekosaur]

I think someone with a better understanding of the source organization will have to weigh in on that; I'm still learning. (To date I just do reviews and work on CI, and am slowly making my way through the source from an operational standpoint (e.g. understanding IPI, LBI, etc.)

[mpickering]

In general, the unit-id of the ghc unit may have no relation to the version of the the ghc compiler itself.

A unit-id can be anything but is prefixed by pkg/version by convention, on darwin systems the package names do not contain vowels for example.

That's something to keep in mind for future, but at least this is an improvement for now.