Now if API returns a bad status, asyn knows about it.

To use the correct term.

removed proof of concept. Made it work for all VMMs of all hybrids.

Turns out it wasn't that different from others. All it needs is to
change a bo record to ao.

Didn't add SD because the mechanism is a bit different.

This commit was done with an inescrupulous "git add ." after several
radical modifications.

Anyway, the API was radically modified and basically the old way the
code worked does not make any sense anymore.

The desired architecture is the following: the API is going to be used
as a class component. Each parameter will be created according to the
desired number of enabled hybrids.

Each parameter should use one simple API function. No information about
the VMM or hybrids itself is stored in the VMMTbl class unless extremely
needed.

This commit leaves a few old parameters that should be removed in the
future such as ADC_VALUE_VMM1, READ_ADC_VMMS, etc. This is only to serve
as a reminder to add those later.

Mostly just change names of files or classes.

Use new API architecture.

See merge request !5

If check is not made, ioc will try to write to register in the beginning and fail, crashing the application.

It wasn't supposed to be here. Should be named configFE only.

According to new VmmTblConfig definition

VmmTbl now inherits from asynPortDriver instead of FrontEndBase.
It has VmmTblAPI as a class component.

Thus, everything that used pRMM->foo(); such as pRMM->setStringParam(addr_list, vmmHybFwVersion_[hyb], pVMMConfig.readFwVersion(hyb).c_str());
are simply foor(); (equivalent to this->foo();)

Everything that used pVMMConfig.foo(); now uses pVmmTblAPI->foo();

configFEN had its name changed to configFE since the last configFE did
nothing.
Old configFE was removed.

In the end, findRegister() was not moved to VmmTblAPI because it seems
to be searching for a given register name based on an epics parameter.

As far as I know this would only be used if we wanted to install the
module and use it's headers.

I don't see why we would do that now.

vmm_config is now called VmmTblAPI. Following [Loki's example](https://gitlab.esss.lu.se/nice/dev-epics-modules/fe-r5560-loki/-/blob/include-api-on-module/r5560LokiApp/src/r5560LokiApi.h?ref_type=heads)
it inherits from RMM API's FrontEndBase, which means it doesn't need
pFEN as a class parameter anymore.

This breaks the whole application compilation, but it was already broken
in the new API structure.

It you compile only with

SOURCES += $(APPSRC)/VmmTblAPI.cpp

in the Makefile, it works. My intention is to keep adding the other
files now.

Other APIS follow the same structure. No need for a cpp file for this.

Add arrays to set channels

Closes ICSHWI-18047

See merge request !4

Just a initial one. Needs to be improved.

It was there because of a mistake.

This does not mean that the configuration file will permanently stay on this folder/subfolder
structure.

It's just a way of letting things more easy to test and reproduce for now.

To fix problems suggested in discussion: !4

channels.template is already added by channels.sub

As received orientation from from E3 team.

Substitution file is used in module build to set channel names, since that shouldn't change
too much with time and particular detector.

VMM and Hybrid numbers are left to be changed in the st.cmd file since that can change more often.

Now, for VMM, the pattern is:
$(R)$(H)$(V)$(C)$(CH)

R: Usually "NDet-VMMHYB-00". No colon after.
H: Hybrid number in range 0-5
V: VMM chip number in range 0-1
C: Colon Between device name and property Should be ":" but is a macro in case anyone
   decides that shouldn't be there anymore.
CH: Channel/register being set. Can be ST, SL, SC, STH, SM or SMX

Also, to make naming more visible and dynamic, stop using substitutions file.