Extract package fetching logic into shared utility

[g-elwell]

Description

This PR extracts the logic for fetching and validating packages into a shared utility which can be used by any commands.

Previously this was implemented in two locations, with more on the way in #101 and #119. Repeating this logic is complicated and prone to errors due to the various scenarios and validation required to gather a list of build-tools-compatible packages to run a command against.

This change fixes a potential bug where the ci and install commands would try to run against unexpected packages (e.g: plugins with a package.json but no src/entrypoints). I am unsure whether this was intentional, as although an entrypoint is not required to run npm install, we enforce the entrypoint directory structure in our projects and use this to differentiate them from other packages that may exist in a workspace. I don't think the build tools should be concerned with packages that don't meet this criteria as the results could be unexpected.

Before

After

[ampersarnie]

Previously this was implemented in two locations, with more on the way in #101 and #119.

We can ignore #119 for the time being, and I'm unsure of when or if #101 will be added - a lot has changed since.

This change fixes a potential bug where the ci and install commands would try to run against unexpected packages (e.g: plugins with a package.json but no src/entrypoints). I am unsure whether this was intentional.

This wasn't intentional and the behaviour you're trying to get here is what is needed, so the ideas and direction work. Code just needs reviewing and testing.

[g-elwell]

@ampersarnie this is now ready, thanks! I think there's potential to improve it in future, but I've purposefully left the extracted utility as close as possible as it was in the build script for ease of review.