Rework Config.js to accept fleets from different envs

[vipulgupta2048]

At the moment, config.js can only accept multiple fleets from a single environment as input with improvements made in #836
The current schema and client code are unable to find compatible workers across multiple environments. To resolve this, a new specification for the workers property is needed that is:

1. Can scale to accept multiple environments and look into multiple fleets within those environments (BC, BM, local devices)
2. Provides backward compatibility to the existing config.js schema in order to not break tests
3. Create as few changes as possible in Core.

[vipulgupta2048]

Request for comments on building the new workerpool property

module.exports =
  [
    {
      deviceType: "genericx86-64-ext",
      suite: `${__dirname}/../suites/e2e`,
      config: {
        networkWired: false,
        networkWireless: true,
        downloadVersion: 'latest',
      },
      image: `${__dirname}/generic.img.zip`,
      debug: {
        dev: true,
        failFast: true,
        globalFailFast: false,
        preserveDownloads: false,
        unstable: ["Kill the device under test"],
      },
      workerpool: [
          {
            workers: ['http://worker'],
            balenaApiKey: '',
            balenaApiUrl: 'balena-cloud.com',
            organization: 'admin',
          },
          {
            workers: ['http://public.device.url', 'http://public2.device.url'],
            balenaApiKey: '',
            balenaApiUrl: 'balena-cloud.com',
            organization: 'admin',
          },
          {
            balenaApplication: ['vipulgupta2048/testbot-vipul', "FLEET2"],
            balenaApiKey: '',
            balenaApiUrl: 'bm.balena-dev.com',
            organization: 'admin',
            shConfig: {
              host: 'ssh.devices.bm.balena-dev.com',
              port: '222',
            }
          },
          {
            balenaApplication: ['vipulgupta2048/testbot-vipul', "FLEET2"],
            balenaApiUrl: 'balena-cloud.com',
          },
        ]

The client will be using new logic to discover devices if workerpool property is present in the config.js. If not, then we will use the existing logic in Leviathan to provide backward compatibility. Ideally, there will be no changes to Core since the config finalized to be sent will be in the same structure.

[vipulgupta2048]

Problems currently to watch out for

• The fleet array searches for the same set of fleets in both BC and BM leading to errors (workaround added)
• No way to specify fleets from both BM and BC together (Main issue)
• Has to be compatible with how GitHub Actions will handle this (Some thinking to be done)

[rcooke-warwick]

"The fleet array searches for the same set of fleets in both BC and BM leading to errors (workaround added)"

Correct - if any fleet in the list doesn't exist in the target environment at the moment, then an error is thrown