[eas-build] Expose generic job's BuildWorkflow

[sjchmiela]

Why

Exposing BuildWorkflow from runGenericJobAsync lets us fetch individual steps and their outputs after the job is complete.

How

• wraps buildWorkflow.executeAsync() with asyncResult and returns the result from runGenericJobAsync alongside buildWorkflow,
• adds outputs to Generic.Job so the user has a way of telling us which steps outputs are to be considered jobs outputs,
• when a generic job finishes, Worker sends a robotAccessToken-authenticated request to a new www endpoint.

Also changes the way we're handling outputsDir and envsDir — we want the outputs and environment variables to be collected always, not only if the step succeeded. And exposes jsepEval so we can use it in Worker.

Moreover, removes outputs from BuildStep. We had two: outputs and outputById, one being updated as we process the workflow and the other not.

Test Plan

Adjusted tests. I've used this version to run a custom job with set-output name test and gotten

[linear]

ENG-13458 Add support for job outputs other than entity IDs

[radoslawkrzemien]

LGTM 🚀

What's the rationale behind returning runResult: Result<void>;?

[szdziedzic]

looks reasonable

[sjchmiela]

What's the rationale behind returning runResult: Result<void>;?

Most importantly, I wanted to be able to return output always, if the job succeeds or fails. This is how it works in GitHub Actions too. Not sure if people use it, but if we can do it too… why not!

I could do { buildWorkflow, error: Error | null } to denote whether the workflow succeeded or failed, or something with type too. In the end I figured we can use Expo's own results library.