Optimize testenv-build and allow multiple NSOs

This patch combines both the more general support for multiple NSOs in the same testenv as well as an optimized version of the testenv-build target. It's no longer small and innocent - not a naive implementation anymore.

For some type of packages, using multiple NSO instances is simply necessary. As an example, a prototype of YANG-push implemented as NSO packages obviously needs a subscribing node and a publishing node. For this support, we have a new env variable called DOCKER_NSO_ARGS which should be included in the command to start the new container - it's really a mere convenience but sets the right label (nidtype=nso) so we can later find the container as well as placing the packages folders (/var/opt/ncs/packages) in an anonymous Docker volume.

Targets that act on multiple containers, such as testenv-build, will automatically find all relevant contains based on a label. Targets that act on a single container, like testenv-cli now takes a NSO env variable to act on a specific container. The name of the default NSO container is still $(CNT_PREFIX)-nso and all commands that act on a single container still act on this container per default. Extra NSO containers should be named such that the name start with $(CNT_PREFIX)-nso, for example $(CNT_PREFIX)-nsofoo. To run a command on the foo container use:

$(MAKE) testenv-runcmdJ NSO=foo CMD="show packages"

The second stage is the optimization of the testenv-build target. The first part of that is by using rsync instead of cp to copy over packages. cp would always copy the files (although this could have been avoided with -u) leading to reading the entire package content once and writing it once. rsync will read the source and destination files, comparing them first and only if differences are found will the source be copied over. This equates to much reduced writes, which is probably a good thing. Reads can be made fast from the buffer cache while writes still need to be written.

Second, rsync logs the changes it makes. We then analyse this log file to decide whether to run request packages reload or request packages package FOO redeploy. This leads to a vast speedup on large system where a package reload can take minutes while a package redeploy is done in a few seconds. In NSO 5.3 and later, package redeploy can be used for changes to configuration templates while for previous version a package reload is required. We look at the NSO version to determine which method to apply.

The 'testenv-clean' target has been replaced with 'testenv-clean-build' which not just cleans but also rebuilds everything from scratch and does a forced reload to ensure a consistent state.

Closes #134 (closed) and #136 (closed).