Implement data-based compiler perturbance

[MattWindsor91]

An idea I had while thinking about #135 is to move the compiler optimisation/moptimisation functionality into a data-driven perturber pass separate from c4t's compiler interface. Something like a YAML table of the form:

- name: "std-opts"
  precondition:
  # Might need a proper boolean language for this, possibly even SQL.
  - compiler: "gcc.*"
  opts:
  - name: "0"
    bias: "size"
    # etc

- name: "outline-atomics"
  precondition:
  - compiler: "gcc.gcc"
    min-version: "10"
    arch: "aarch64.8"
  - compiler: "gcc.clang"
    min-version: "12"
    arch: "aarch64.8"
  flags:
  - name: "outline-atomics"
    allow-empty: true
    choices: ["moutline-atomics", "mno-outline-atomics"]

This table would either be embedded into c4t-perturb or just read from config, with an example given as part of c4t's distribution. It'd be read in by the perturber, with the other parts of c4t not bothering with it.