Previously, it was the case that running
```
$ iocsh -r module -l cellMods
$ iocsh -l cellMods -r module
```
would both work correctly, but if you looked at the IOC log it was not
clear why that was the case; in the former case it _appeared_ like we
were finding the module before setting `EPICS_DRIVER_PATH`. This only
worked because this variable is exported from the shell.

This change forces the `-l` flag to be processed _before_ all of the
other flags in order to ensure that paths are determined first.

E3-884: Make non numeric version reinstall prohibited

See merge request e3/e3-require!100

E3-944: Warn if building from install path

See merge request e3/e3-require!99

If a user runs the build from the E3_SITEMODS_PATH, then it can happen that
false dependencies get registered due to how the generated .d files are
parsed to determine module dependencies. Specifically, if you have header
file being used that is located at

${E3_SITEMODS_PATH}/e3-module/module/src/header.h

and it is _not_ being installed, then the dependency parsing script will
see a dependency as an absolute path, and so register that your module
depends on the module `e3-module` version `module`, which is obviously
not what was intended.

While we don't want to stricly _prevent_ a user from building there, it
seems wise to _warn_ a user that there may be unintended consequences.

E3-731: Improve tests

See merge request e3/e3-require!98

Previously, the wrapper fixture would set some environment variables
when running `run_make`; this meant that you could not debug a test
case by simply navigating to the test directory and trying to build
the generated module. This change fixes that.

E3-927: Remove IOCNAME:exit PV from standard E3 iocs

See merge request e3/e3-require!97

As part of E3 there was a decision to remove the IOCNAME:exit.
This pv could lead to unauthorised people to stop and iocs also
is not easy traceble.

In order to do this the BaseVersion PV is now provided by require
and softIocExit.db is no longer loaded.

E3-894: Fix issue where non-existent versions would cause the build to hang

See merge request e3/e3-require!95

The ultimate issue here was that we performed a
```
cat $( ... ) | sed '1d'
```
and if that inner block was empty, then `cat` reverted to waiting for user input. The
error also came up with non-specified build numbers, so we need to make sure that those
are also being fetched correctly.

The upshot is now `<module>_VERSION` will automatically fetch the correct build number;
the only potential downside is that if we have a newer version in `${E3_SITEMODS_PATH}`
in comparison to `${EPICS_MODULES}` (read: cellMods), then it won't pick that up. However,
this seems to be a pretty special corner case.

E3-921: Add test to ensure that failed architectures cause build to fail

See merge request e3/e3-require!94

This adds a test that checks that if a single architecture fails, then the build
fails as a whole.

There are some slight complications in terms of writing good tests, since we do not
want to use real architectures. Since the source files are converted from
`SOURCES -> SRCS -> LIBOBJS` and we finally have the dependency
```make
${DEPFILE}: ${LIBOBJS}
```
we need to ensure that `LIBOBJS` is properly populated before we get to this point.
The challenge, however, is that `LIBOBJS` is defined (in terms of `SRCS` as
```make
LIBOBJS += $(addsuffix $(OBJ),$(notdir $(basename $(filter-out %.$(OBJ) %$(LIB_SUFFIX),$(sort ${SRCS})))))
```
and `LIB_SUFFIX` is set in `${CONFIG}/os/CONFIG.Common.${T_A}`. This is why
we need to do the workaround of hand-defining it at the beginning.

E3-920: Set custom E3_MODULES_PATH for test target

See merge request e3/e3-require!93

The test rule for e3 modules actually does a cellinstall and run the
tests inside this temporary installation. The cellinstall needs to
overwrite some path variables to work this variables were not accessible
through the test rule as they are just changed if cell is on
MAKECMDGOALS. This made impossible to use the standard path variables
inside module's custom test rules.

To fix it the same mechanism used in cellinstall is implemented for test
and the variables paths are now overwritten. This makes possible ie. to
use E3_MODULES_INSTALL_LOCATION_BIN inside custom test rules.

This commit also introduces an unwanted behavior. As the test rule is
now overwriting the standard path variables it cannot longer be along
with the install rule. For example, running `make test install` will
install the module inside the test dir. This is a known issue for
cellinstall as well and a restructure of the Makefile code should be
made to isolate the rules.

E3 924: General require cleanup

See merge request e3/e3-require!92

E3-895: Use bash also for debug on CONFIG_SHELL

See merge request e3/e3-require!91

E3-662: Improved IOC startup output

See merge request e3/e3-require!90

E3-453: Remove EPICSVERSION loop

See merge request e3/e3-require!89

This is necessary for the following reason: the previous mechanism used an
eval/call combination that required SUBS and TMPS to be exported on a previous
pass through. This allowed us to use `vpath` for each specific file in order
to locate the correct source files.

In order to avoid that, we add two new ingredients:
* `VPATH` instead of `vpath`, since it allows us to have variables
  that are expanded later
* `.SECONDEXPANSION`, which allows a target (`db_internal`, in this case) to
  perform a second variable expansion at the _end_ of the pass through.

All of this is necessary because the typical module makefile looks like:
```
include driver.makefile

SUBS += ...
```
i.e. `SUBS` and `TMPS` are defined _after_ the inclusion of driver.makefile. If
we don't want to force a re-write of every single module makefile, we needed
to do some of the above changes.

Note that there is something surprising here: `EXCLUDE_ARCHS` _filters_
the architectures (i.e. runs it as %arch%), while `ARCH_FILTER` matches
exactly. This is exactly backwards from what the names suggest.

However, I am leaving this as is for the time being since there are
possibly existing wrappers that use these two variables in this way; a
further investigation should be done to ensure that we can improve this
in some sense. If we make such a change, we should regard it as breaking.