idea: {{deps.foo.bar.prefix.relative}}

Start by tracing how brewkit handles the existing {{prefix}} and dependency template values during $ bk build; the issue does not name a file or test. Define the relative dependency-prefix behavior and verify that the example working-directory: ${{prefix}}/libexec can resolve the requested {{deps.foo.bar.prefix.relative}} value without changing podman source.

Satisfies a very weird problem set. @ABevier is packaging podman.io, which has oddly strict requirements for where to find things:

Error: unable to start host networking: "could not find \"gvproxy\" in one of [/usr/local/opt/podman/libexec /opt/homebrew/bin /opt/homebrew/opt/podman/libexec /usr/local/bin /usr/local/libexec/podman /usr/local/lib/podman /usr/libexec/podman /usr/lib/podman $BINDIR/../libexec/podman].  To resolve this error, set the helper_binaries_dir key in the `[engine]` section of containers.conf to the directory containing your helper binaries."

Since {{prefix}}/libexec is one of the options, one of my pitches to him is:

dependencies:
  foo.bar: ^8
build:
  script:
    - run: ln -s "../../../foo.bar/v8/bin/foobar" foobar
      working-directory: ${{prefix}}/libexec

Assuming {{prefix}} == $(tea --prefix)/podman.io/v$x, I'd expect {{deps.foo.bar.prefix.relative}} == ../../foo.bar/v$y. This is tighter coupling than I'd like, so we should (probably) discourage its usage, but it would solve issues like the above without having to alter the source code of podman. Which is the other option.