Improvements to alarms

When a configuration is changed the blockserver generates `C:\Instrument\Apps\EPICS\CSS\master\AlarmServer\config\Instrument.xml`
file base don alarm info fields in records loaded from epics *.db files, the xml file is then loaded into the mysql database on the instrument via the `alarmconfigtool` and then the alarm server and GUI look at, and change, mysql directly (e.g. to record alarm acknowledge).

Currently the only way to permanently control what PVs are in the alarm view would be to edit the *.db files loaded by IOCs and add/remove the “info(alarm, …) ” entries in PV records, but any such db changes would be lost on an ibex update.

To make the system more flexible we should look at how we implement the alarm configuration. We could for example have very little, if anything, added by default, and then it would be up to a scientist to specify alarm setup for each PV/item on an OPI for components/configurations. But we would need to do some requirements gathering across instruments to determine what everybody needs and hence the best way to make the system behave for everybody.

A simpler and quicker to implement solution, but which may not be flexible enough, is to just make whether an IOC (and some pre-defined sets of pvs) were present in the alarm view via an IOC macro (like specifying the COM port when adding an ioc). So this would let you chose if an IOC was there at all, but which PVs would be included would have been pre-determined by ibex. How much flexibility on choice of PVs to include verses just having an IOC included at all do you need? If a PV is added for everybody to the alarm view, unless high/low etc are also specified it would usually just sit there as saying it was OK (but may go into alarm if the device is disconnected)