core: FIPS for fastpath and RDP security fixes

- fixed invalid stream position if extEncryptionMethods is not used
- enabled 56bit rdp security method
- fixed entropy reduction of the keys for 40 bit and 56 bit
- added rdp security incl. FIPS for fastpath output
- added FIPS encryption to fast path input
- fixed FIPS key generation in server mode
- fixed stream length correction in FIPS mode
- added rdp encryption for licensing packets (apparently some clients,
  specifically cetsc, require the license packets received from the
  server to be encrypted under certain RDP encryption levels)
- replace errnous virtual extended mouse event in focus in event
libfreerdp-core: fix disconnect reason
Merge pull request #1765 from nfedera/fix-2014-04-02-01

core: FIPS for fastpath and RDP security fixes
Merge pull request #1766 from nfedera/fix-2014-04-02-02

libfreerdp-core: fix disconnect reason
sec-rdp: fixed *_establish_keys for keys > 256 bit
sec-rdp: limit server side key size to 2048 bit

Current code doesn't handle keys > 2048 bit properly in multiple places.
To prevent problems make sure that no larger keys are used for now.
sec-rdp: fixed cleanup in key error case
Merge pull request #1767 from bmiklautz/fix/rdpsec

RDP security fixes
Ensures that the static virtual channels are started

before virtual channel data can be received
Merge pull request #1768 from FreeRDP/mh-svc-start-fix

Ensures that the static virtual channels are started
libfreerdp-core: fix transport_check_fds

This patch fixes an issue with hung clients connected to FreeRDP server:

- Removed the completely useless inner while loop which used the transport
  receive buffer stream position as break contition: The transport receive
  buffer stream is replaced after each iteration of this loop with a fresh
  instance from a pool which has the position set to 0. Thus it was
  technically impossible that this loop would ever be run twice.

- We must not always return if transport_read_nonblocking returns 0:
  transport_read_nonblocking() is also called in transport_write() and
  therefore it is possible that the stream position of the transport
  receive buffer is already > 0 when entering transport_check_fds.
Merge pull request #1769 from nfedera/fix-2014-04-03-01

libfreerdp-core: fix transport_check_fds