Support local paths to additional code

[dafyddstephenson]

This one is a bit trickier than #4 :
The current implementation of the AdditionalCode class assumes that all code associated with a blueprint is coming from a single repository. Take a look at the relevant section in cstar_blueprint_roms_marbl_example:

      additional_code:
        source_repo: 'https://github.com/CWorthy-ocean/cstar_blueprint_roms_marbl_example'
        checkout_target: '69ee87b554082c46e3f138a9b3faf17439966e90'
        source_mods:
          - "source_mods/ROMS/bgc.opt"
          - "source_mods/ROMS/bulk_frc.opt"
          - "source_mods/ROMS/cppdefs.opt"
          - "source_mods/ROMS/diagnostics.opt"
          - "source_mods/ROMS/ocean_vars.opt"
          - "source_mods/ROMS/param.opt"
          - "source_mods/ROMS/tracers.opt"
          - "source_mods/ROMS/Makefile"
          - "source_mods/ROMS/get_makefile"
          - "source_mods/ROMS/Make.depend"
        namelists:
          - "namelists/ROMS/roms.in_TEMPLATE"

It seems weird to require that if the user wants to use local files that these would have to be git controlled, so the class will have to be restructured a bit.

The main issue here is that a single AdditionalCode object currently represents a list of files, whereas, e.g. InputDataset is one per file. I think there should be some distinction in how we handle these two classes, as it makes a lot more sense for a bunch of, e.g. source code modifications to co-exist in a single place under one source header than it does for a bunch of disparate forcing datasets.

Any ideas? @TomNicholas @matt-long @NoraLoose