When MC is running on a processor with a control subnet and a user
attempts to access the UI via the control subnet, the return _config.local.json
needs to reflect the CS LAN IP address for the processor rather than the LAN IP Address.
In order to accomplish this, there will now be 2 config files written to disk on startup:
1. the original file, /user/programX/mcUserApp/_local-config/_config.local.json
2. A file with the correct CS IP Address /user/programX/mcUserApp/_local-config/_config.cs.json
When a user requests the _config.local.json, the processor will compare the remote IP address
with the CS LAN IP Address and determine if they're in the same subnet, the assumption being
that if the IP Addresses are in the same subnet, then the app or end user is on the CS LAN and needs the CS config.
If the addresses are in the same subnet, then the contents of the _config.cs.json will be returned.
In some scenarios when working with NVX, a route is intended to use the
secondary audio (NAX) path instead of the primary audio path. A route
that's both `Video` and `SecondaryAudio` should be considered a
dual-path route instead of a single path.
Added the `ILightingScenesDynamic` interface to add an event for devices that support retrieving scene data from the lighting system at runtime. Also added the `sortOrder` property for the `LightingScene` type to allow for control over the sort order of scenes on the UI
Due to how the `BeginPolling` method was written and being called, there
were situations where multiple PollTimers were created, causing there to
be multiple messages sent to the end point for each poll cycle.
In order to match up with how existing front-end apps are expecting to
recieve data for devices that implement the `IHasInputs<T>` interface,
there is now an IHasInputsMessengers that is implemented for devices
that implement `IHasInputs<string>`, `IHasInputs<int>` or
`IHasInputs<byte>` interfaces.
In order to satisfy the requirements for the `MessengerBase` class, the
`ISelectableItemsMessenger` class needs to take an `IHasInputs<T>`, as that is
the device that implements `IKeyName`. We may want to consider adding a
`IHasInputsMessenger` specifically for those devices that implement that
interface vs the `ISelectableItemsMessenger`.
`CrestronGenericBaseDevice` was NOT calling `base.CustomActivate()` in
it's `CustomActivate` override, causing the
`CreateMobileControlMessengers` method to not be called as expected when
plugin devices were inheriting from `CrestronGenericBaseDevice` or
`CrestronGenericBridgeableBaseDevice`.
If the grant code was not provided, the `mobileadduiclient` console
command would fail silently. The command now checks that the correct
number of arguments was provided and prints an error to the console of
one is missing
