PD comms introduction

[bytedreamer]

I updated the messages to use defined command types to remove the usage of numeric numbers in the classes.

My recommendation is to create the following base classes.

• IncomingCommand
• OutgoingCommand
• IncomingReply
• OutgingReply

If it makes sense, use IncomingMessage and OutgoingMessage.

[bytedreamer]

It might be easier to think of messages as Incoming or Outgoing, rather than PD or ACU.

[dxm007]

We just reviewed this stuff via a virtual chat, summary of where we are...

• We presently have Messages.ACU.Reply and Messages.IncomingMessage classes which have nearly identical message parsing logic. Leaving it as-is for now because Reply has a dependency on Device whereas IncomingMessage replaces that with a more generic IMessageChannel interface.
• In next incarnation of this code, ^^ Reply will derive from IncomingMessage but doing so now would require us to retest existing code that parses replies (all of it?)
• We have beginnings of OutgoingMessage in Messages.PD.Reply and yes, at some point that logic will be factored out into a more reusable OutgoingMessage base class. Leaving that as an exercise for the future
• When this work is taken to its eventual end, we should end up with a Message base class, Incoming/Outgoing Message classes driving from that and then Incoming/Outgoing Command/Reply deriving from those. BUT... we should NOT need any of command- or reply-specific classes deriving from those. Actual command/reply types and their payloads will be handled by the set of classes in OSDP.Net.Model namespace. Messages are generic containers responsible purely for building/parsing byte buffers.