Generic Path Searching

Currently `which` is used to find FVP plugins in $PATH. But new FVP builds no longer mark the plugins as executable so they cannot be discovered with `which`.

One proposed solution is to introduce "path sets" into the yaml:

run: params: --plugin: ${path:FVP_PLUGIN_PATH}/ScalableVectorExtension.so

(It's slightly weird having the parameter as the thing following the macro but there is already president for that with ${param:configdir} ).Then we can a section to the config:

run:
  paths:
    FVP_PLUGIN_PATH:
      - /my/place
      - /my/other/place

The base FVP config file could do:

run:
  paths:
    FVP_PLUGIN_PATH:
      - $(dirname $(which FVP_Base_RevC-2xAEMvA))/../../plugins/$(basename $(dirname $(which FVP_Base_RevC-2xAEMvA)))

Which I think would get us the common path. Higher layers would add paths, and the rules dictate those new list entries would be merged below the existing ones. So you would probably want to define that the search order is from bottom to top of list.This approach is generic and extensible and means we don't have to bake in more hardcoded knowledge about the FVP into Shrinkwrap.

Would we want to separate the mechanism for btpaths and rtpaths?

How does this interact with host vs container? Are all paths supposed to be inside the container already? Or do we need to map them? How does it interact with existing btvar/rtvar paths, which do get mapped? Would it all be simpler to just define a btvar/rtvar "unmapped_path" type?