valueAlarm rule should allow alarm messages to vary for different triggers

There are multiple ways to do this.
- Expand the NTScalar Normative Type to include strings such as `valueAlarm.highAlarmMsg`. These would then be settable through the normal methods, including `put()`s. The valueAlarm handler would simply need to check that the additional fields were present and act accordingly. The main disadvantage would be that these would not be true NTScalars (complying with the spec). The big advantage is that the alarm messages could be inspected externally and solid validation applied.
- Add methods to the handler methods (`put()`, `post()`, `open()`) to intercept settings intended for the handlers and not for the Value. The handler method would be responsible for popping it off the dictionary so that it didn't blow up in the p4p Value. As an example, `valueAlarm.highAlarmMsg` would not have a field in the Type. Instead the handler methods would detect it, act on it, and then remove it. This would mean that NTScalar fields would be unmodified, but that a `put()` of the alarm message would probably not be possible (need to check), and it would not be possible to externally check the alarm messages.