XD-2118 provide a shell command processor

Implements a processor and sink that can execute a shell command and stream using stdin and stdout. For example, this may be used to execute a python script.  The ShellCommandProcessor requires an AbstractByteArraySerializer (from SI ip). The module is configured to use CRLF by default but supports the same encoder options as the tcp modules.

Current constraints/assumptions

* The shell command must be written for streaming data. That is, runs as a server process and operates in a request/response style. See src/test/resources/echo.py. 

Currently to work in a stream, the external process must not write anything to stdout initially, only respond to data on stdin (in the processor case) or consume from stdin (in the sink case).  Additional constraints and assumptions:

* The shell command must comply with the configured serializer to delimit the payload (e.g., '\r\n' for the default CRLF encoding). See src/test/resources/echo.py.  

* The modules currently produce and consume String only, charset=UTF-8 but is exposed as a module option 

* Anything required for running the command must be available on the container in which the module is deployed (e.g. python installed)

Module options supported:

* command - the shell command (required)
* workingDir - the path for the process working dir (optional)
* redirectErrorStream - redirects stderr to stdout if set to true. Not generally recommended...
* charset - e.g. "UTF-8" for String encoding
* encoder - The encoder name: CRLF, LF, NULL, STXETX, RAW, L1, L2, L4. Same as tcp modules
* environment - add environment variables to the process as comma-delimited name-value pairs, e.g. FOO=foo,BAR=bar
* bufferSize - The maximum message length (2048) 

This PR does not include integration tests, but I have tested manually across transports in singlenode with various configurations of:
 
        stream create shelltest --definition "http | shell --command='python <spring-xd-project-root>/extensions/spring-xd-extension-process/src/test/resources/echo.py' | log" --deploy

Currently, error handling is an issue. When the module starts, it waits for 1 second for any input on stderr (if not redirected). This works in the test case, but is not robust, as it could take longer for the external process to start up and report an error. Any message on the error stream is simply logged as an error.  Ideally, there would be a background thread that continuously polls stderr, but I haven't had much success with this. Looking for suggestions.  Currently errorTest() correctly produces the following output:

1:17:47,832 DEBUG main process.ShellCommandProcessor - starting process. Command = [python doesnotexist.py]
11:17:47,851 ERROR process-error-monitor process.ShellCommandProcessor - python: can't open file 'doesnotexist.py': [Errno 2] No such file or directory
11:17:47,852 DEBUG main process.ShellCommandProcessor - process started. Command = [python doesnotexist.py]

An alternate implementation of the error monitor should satisfy the above at a minimum. Ideally without requiring an initial timeout and able to continually capture any data from stderr. 



 
I don't think `RAW` makes sense here; raw means there is no message delimiter; the end of the stream denotes the message end so there's no "stream" of messages per se.

Not sure it makes sense to change the mixin, maybe just don't document `RAW` as an option here.