feat: generate params for maestro based on envs

[JulienLeal]

Why

This change enables secure and flexible test configuration by allowing dynamic environment variables to be passed to Maestro flows via command-line parameters. This addresses the need to:

• Avoid hardcoding sensitive values like credentials in test files (GitHub/community discussions around secure test configuration)
• Support environment-specific configurations in CI/CD pipelines
• Align with Maestro's parameter handling best practices (documentation reference)

Example Scenario

Injecting API keys dynamically in CI:

build:
  name: Build and Run Secure Tests
  steps:
    - eas/build
    - eas/maestro_test:
        inputs:
          flow_path: .maestro/auth-tests/flow.yaml
          env: 
            AUTH_API_KEY: ${PROD_API_KEY}  # From CI secrets

Corresponding Maestro flow (.maestro/auth-tests/flow.yaml):

appId: com.example.app
jsEngine: graaljs
---
- evalScript: ${console.log("API Key:", AUTH_API_KEY);}

How

Implemented support for passing environment variables through -e flags following Maestro's external parameters pattern

Test Plan

yarn test src/steps/functionGroups/__tests__/maestroTest.test.ts

[JulienLeal]

bump @szdziedzic @sjchmiela

[sjchmiela]

Hey, thanks. Wouldn't it be easier to use MAESTRO_* variables that are automatically exposed within the flow?

https://maestro.mobile.dev/advanced/parameters-and-constants#accessing-variables-from-the-shell

I see one problem which is that we currently don't apply templating/interpolation to env step attribute, but this is something we're planning to do soon either way. Then, instead of having two env on a call to eas/maestro_test (top-level and under inputs) you'd do (in a Custom Build):

build:
  name: Build and Run Secure Tests
  steps:
    - eas/build
    - eas/maestro_test:
        env:
          MAESTRO_AUTH_API_KEY: ${ eas.env.PROD_API_KEY } # From CI secrets
        inputs:
          flow_path: .maestro/auth-tests/flow.yaml

On a separate note I would recommend considering moving to EAS Workflows. You could orchestrate multiple builds on different platforms, run Maestro tests conditionally, use different EAS Environments for different jobs and lots more.

[JulienLeal]

@sjchmiela I didn't think this option. I'll test right now, thanks <3