Change xstate plugin(s) to look for node_modules/.bin/xstate or node_modules/@xstate/cli

[richtera]

During dev, if you include the @xstate/cli into your dependency list, the xstate plugin should use the exact version (or preferably the same binary) to execute the typegen. Recently the typegen has changed and it's been hard to keep all the development machines with various vscode, intellij and manual execution of xstate typegen in sync. I have added yarn typegen to execute typegen with the version of the cli that matches what we want, but currently can't rely on it, because the xstate plugin is unaware of which version is the preferred one.

[Andarist]

Implementation notes:

1. we could remove @xstate/tools-shared and move its code to @xstate/cli. The extension could just import from it directly (it would be bundled into the extension's code) but prefer using a locally resolved copy.
2. We can also see how this sort of logic is implemented in Prettier's extension here. I'm not entirely sure if we actually need to replicate it 1 by 1, some of this logic seems to be arbitrary and supporting some niche use cases. The purpose of our tooling is different than Prettier's - and our logic is much more coupled to the version of XState and @xstate/cli. I don't see a strong reason to resolve global installations and stuff like that.
3. It's also worth noting that when running as a web extension a different resolver should be used. Prettier extension is implementing this here

[richtera]

True. The reason why it's similar to prettier is that the output is run through prettier and if the prettier format were to change the output would also not match and cause addition git commits flipping the output back and forth coming from different dev machines, but I do agree that prettier is a completely different beast. How about requiring a version inside of the machine typegen attachment and use that version? Then it would only change on purpose. The only drawback is that the extension would need to dynamically download and install the appropriate generator.

[Andarist]

Hm, I think that would somewhat complicate the system. I don't disagree with loading the local version of the typegen generator~. I totally think that we should do this and I think it's very much doable using the existing piece, to make it easier though we should reorganize the packages structure a little bit.

Dynamically downloading generators also have the drawback of requiring internet access and introducing a dependency on some external service, like a CDN. It's probably better for us to just use what is available locally as that should be enough to cover all the cases.