Refactor parts of the ParseConfiguration

[jonjohnsonjr]

This thing is a bit of a beast, so I'm not going to do it all at once, but some of these string replacements are incredibly mutate-y, so I've rewritten them to be a bit more functional.

This still isn't great, but I think it's better than before.

[jonjohnsonjr]

Drafted this because I'm not 100% happy with it. I've tried to model how things are working with these different phases of ParseConfiguration/Compile:

(link)

I'd love to refactor the code to look more like this so that it's easier to change/fix the code without accidentally breaking things.

[Dentrax]

Thanks @jonjohnsonjr! Could we also add 2 test cases to check:

1. subpackages[].range[].pipeline[].working-directory[].pipeline is evaluating without any issues
2. the following package build exists with 1?

package:
  name: foo
  version: 1.0.0
  epoch: 0
  description: Test
  copyright:
    - license: MIT

environment:
  contents:
    packages:
      - build-base
      - busybox

data:
  - name: packages
    items:
      foo: foo
      bar: bar

pipeline:
  - runs: mkdir foo bar

subpackages:
  - range: packages
    name: "${{package.name}}-${{range.key}}"
    description: Package ${{range.value}}
    pipeline:
      - working-directory: ${{range.key}}
        pipeline:
          - runs: exit 1

update:
  enabled: false

[jonjohnsonjr]

is evaluating without any issues

Added a sub-pipeline to one of the tests that includes subpackages, that works fine.

the following package build exists with 1?

I don't think we have any tests that are supposed to fail but I ran that locally with my change and got:

ERRO failed to build package: unable to run subpackage fail-bar pipeline: unable to run pipeline: unable to run pipeline: task exited with code 1