repository structure: importing third party code

in many instances we follow a vendor branch approach
- unmodified third party code updated on vendor branch
- changes merged into our master
sometime the source distribution is easier than the git code ito compile, for example less tools may be needed e.g. platform independet pre-processing, such as running of flex/bison etc, may be done as part of generating a source distribution

some software is available on github, can it be incorporated more directly?

## Add upstream directly as a submodule in support?

this may be fine if we need to make no changes and can call their build system directly.
however we need to think how it goes with out workflow e.g. we currently add support submodules
to EPICS top and have a jenkins jiob to warn is we forget to push a support submodule we worked on. But in this
case we have pinned an external module that looks like a support module but may update independenty, we don't want the
changes until we expliclty pull, but don't want it permanently in error

## Fork all third party modules and add to support?

this gets around above problem in that support submodule it will only show it needs an update if we do that separately. Do we try and keep main branch in sync with upstream/main and have an "ibex" branch, or just modify main directly and merge upstream/main to this periodically

# Handling modules where we adjust the build system e.g. make it "epicsy"

we can either:
- add EPICS files directly in our fork of thirdy party code, or
- to our own separate repo, add unmodified third party code as a subdirectory submodule