fix(atomic): make sure Stencil start on the good port

[louis-bompart]

Proposed changes

What's going on

Netlify even tho it does some framework detection, does not negotiate the 'targetPort' with the frameworks.
To understand why, we have to understand a bit how Netlify works, which is quite simple: As our CLI.
By that, I mean that the Netlify-CLI will do the same thing that we do: start other CLI (like stencil-cli in this instance).

However, what it doesn't do is the 'port mapping' between the option given in input and the underlying CLIs.

Proposed fix

To alleviate that issue, I circumvent the Netlify-CLI by relying on the fact that it's good practice to 'carry the parent process.env around when spawning child processes.
This allows me to spawn netlify-cli with the STENCIL_PORT in its env, and to get it back when the stencil config is evaluated.

We still pass targetPort so that when netlify-cli wait for the port of the framework to be open, it waits on the good one.

Testing

Current FTs are enough, tho for some obscure reason, it was working on Linux. (like, the expected behaviour from our perspective was OK, the fact that it worked in Netlify is pretty nebulous tho).

[github-actions]

Thanks for your contribution @louis-bompart !
When your pull-request is ready to be merged, check the box below to merge it

• Merge!

[github-actions]

Pull Request Report

PR Title

✅ Title follows the conventional commit spec.

[ThibodeauJF]

Very elegant, thank you 💯