Added a local channel ID column to the channel panel view.

A list of local channel IDs is cached from the server and stored in the default channel controller. The cached channel ID is then used to look up the local channel ID from this map variable, set to a local ID variable stored within the channel status.

This new column is accessed by right clicking the header row and selecting the option to show or hide the column. The visibility of this column is stored in the user preferences node to determine whether or not to display the column on startup.
Issue: MIRTH-3260
Added the ability to use velocity template variables when routing via a channel writer.

The new channel ID field will display the unique guid for any channel selected using the combo box. Alternatively, the combo box now dynamically updates based off of what's typed into the channel ID field. If the text matches a channel's unique id, the combo box will display the name of the channel, however, if a channel does not exist for the entered text, the combo box will default to "<Channel Not Found>". Also, if a velocity template variable is used or is empty, the combo box will reflect this state as well with a corresponding option, "<Map Variable>" or "<None>".

This feature is achieved by adding a document listener to the underlying field to handle the aforementioned logic. Because these two fields are now coupled, additional logic has been placed to ensure that an infinite loop does not occur when the user types into the field.
Issue: MIRTH-2961
MIRTH-2181, MIRTH-3323: Both the HTTP Listener (for responses) and the HTTP Sender now have the ability to send binary content. The listener now has a "Response Data Type" option that automatically Base64-encodes data going back to the source. The sender also has a "Data Type" option that works essentially the same as it does for TCP and File.

Also, both the receiver and dispatcher have been modified to better handle incoming binary data. When the receiver gets a request with a binary content type, it will automatically convert that to a byte array and store that in the RawMessage instead (assuming Plain Body is enabled). When the sender gets a response with a binary content type, it will do the same thing, so it's now possible to send and receive binary content without doing crazy charset hacks like windows-1256 stuff.