chore: lint-versions to do semver satisfy check

[jorenbroekema]

Sooo after we merged the last PR, in the release workflow we would run changeset version which bumps @lion/core.

lint-versions was ran afterwards on precommit and started complaining, because it decided 0.21.1 was not okay with ^0.21.0, however, this should be okay because we use caret.

I adjusted the script to do a semver.satisfies which takes the version (0.21.1) and checks if it satisfies the range (^0.21.0).

There is also a situation where two ranges are compared, e.g. when root package.json has a devDependency and a subpackage has that same dependency (but as a real dependency), e.g. semver ^7.1.3 and ^7.3.5.
I'm not sure if we're supposed to be comparing them, but I guess it's a good practice to have them aligned from semver perspective.
In this case, you can convert both ranges to full ranges with semver, and check if they sufficiently overlap: one range needs to fully contains the other. That makes them compatible, I think, meaning they would always resolve to the same installation which gets deduped. I tried to check it with a small manual test and it seemed ok:

[changeset-bot]

⚠️ No Changeset found

Latest commit: 41caea7

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR