Perform a refactor to make it easier to support different environments besides `fddaq`

[jcfreeman2]

This can be though of as a generalization of the work I did last year on an fddatautilities target package, #361, and will likely reuse some of the work I did there. In a nutshell, what we ideally want is to make it eas(y/ier) for Software Coordination to support different development/running environments as the need arises. Right now we have a fairly monolithic structure which supports fddaq (and, going back a couple of years, nddaq) and a single Python environment. In the coming months, we'll want to split off different environments which don't need the full set of packages we've been using for fddaq - e.g., if you're monitoring or using Run Control, you don't need listrev or dpdklibs.

What I plan to do is come up with a repeatable way for Software Coordination to add new software environments when the need arises. Some of this will involve removing assumptions about fddaq and nddaq which exist in wf-setup-tools.sh and build-release.sh; also it'll need to be determined where the various release YAML files will go. And of course, part of the testing process for the change will be a check to make sure we can reproduce the currently-existing fddaq + standard .venv environment - again, this is really just a refactor.