[HAL] KSDK update - step 1
[K64F] KSDK update - part 2, some parts of HAL update to the new KSDK
[K64F] HAL update (KSDK 1.0)
[K64F] cmsis system header file update
[K64F] Fix gpio - port addresses, old KSDK code removal, modification in utilities

	- warning: utilities are not compatible with KSDK, few tweaks were required
	- lpuart not generic, does not compile for K64F (removed)
Fix KL25Z connect problem with some USB 3.0 hosts

This change fixes a problem I've encountered using the Freescale KL25Z as a USB client device when attaching to a USB 3.0 port on a host PC.  I've personally observed the problem on two PCs, one a Dell running Windows 8.1 and the other a custom-built Windows 7 machine with a Gigabyte mobo.  Several other people on the Web have reported what appears to be the same problem.  It even appears to happen with some Macs - so it's apparently not Windows-specific or Windows-version-specific.  But it does seem to be USB 3.0 specific, and one report speculated that the common element is the Intel Haswell chip set on the host side.

The problem can be worked around by using USB 2.1 ports (many PCs have a mix of 2.1 and 3.0 port hardware) or by connecting a USB 2.1 hub between the device and host.  I have USB 2.1 ports on both of my testing machines, and this solution does work for me.  But I wanted to fix it at the software level if possible, so that my project would work for people who might only have USB 3.0 ports available.

I tracked down the problem to a timing issue that seems to cause the device and host to get out of sync with respect to flow direction on the USB connection during the initial handshake. It seems that the host can issue a CONTROL OUT token at a point where the client is trying to send the response for a previous CONTROL IN token. I found a note in some USB 3.0 reference material that this situation can occur, and that the client can resolve it by sending a zero-length ACK, which tells the host that the client isn't ready and that the host request should be repeated. 

My fix sends a zero-length reply in USBDevice::controlOut() when the control flow error is detected, and also explicitly sends the pending CONTROL_IN packet.  This appears to fix it reliably on my machine.  I'm not entirely confident about the fix, though, since I don't feel I understand the USB protocol or the mbed code in enough depth.  I'm submitting the change here in the hope that someone with a deeper knowledge of the mbed code can determine if this is a good fix, and if not can hopefully use it as the starting point for a better solution.  

Note that I submitted the same pull request via the mbed source control system, but I was advised by another mbed user that I should also submit it directly on github.  Apologies for any confusion caused by the redundant submissions.
Modified the TARGET_GHI_MBUINO/PeripheralNames.h and targets/hal/TARGET_NXP/TARGET_LPC11UXX/TARGET_GHI_MBUINO/PinNames.h to reflect the mBuino base hardware;
I commented out the non useful SPI pins and Serial pins from our hardware build;
For pwmout, I removed the non useful pins and added two more pins that are part of our hardware build.
Revert "Modified the TARGET_GHI_MBUINO/PeripheralNames.h and targets/hal/TARGET_NXP/TARGET_LPC11UXX/TARGET_GHI_MBUINO/PinNames.h to reflect the mBuino base hardware;"

This reverts commit 6b910f27637f2956bea6bfbeee97610d266937ce.
Removed the Peripheral Pin Definitions from the xxx_api.c files (analogin, i2c, pwmout, serial, & spi) to follow an example from Erik O. from this platform: https://github.com/mbedmicro/mbed/blob/master/libraries/mbed/targets/hal/TARGET_Freescale/TARGET_KLXX/TARGET_KL46Z/PeripheralPins.c to allow for advanced compatibility of platforms;
Subsequently, the Peripheral Pin Definitions were added to the file called PeripheralPins.c to accommodate the removal of the definitions from the main xxx_api.c files and added it to each respective Target folder;
Added PeripheralPin.h to point to the PeripheralPin.c files in the target directories.
Modified the linker script for the ARM Micro, Standard, and GCC to accommodate for the specific chip that the mBuino platform uses LPC11U24FHI33/301 which is 6kB in the SRAM vs 8kB;
Added ('GHI_MBUINO',     ('ARM', 'uARM', 'GCC_ARM')), to the OFFICIAL_MBED_LIBRARY_BUILD section of build_release.py.
The following changes were based on the request by Martin Kojtal:
Removed the pin definition comments from the xxx_api.c files;
Added GHI_MBUINO to the build_travis.py target section.
Modified PinNames.h to have correct pin mapping and enabled some elements in device.h for testing.
Modified device.h so all supported devices are enabled.
[HAL] K22F - CMSIS files, target.py addition
[NUCLEO_F334R8] Fix I2C clock issue
Merge pull request #426 from bcostm/master

[NUCLEO_F334R8] Fix I2C clock issue
Merge pull request #414 from mjrgh/patch-1

Fix KL25Z connect problem with some USB 3.0 hosts
Modified PeripheralNames.h and PeripheralPins.c to reflect Gambit peripheral mapping
Fixed device.h copyright comment section
Merge pull request #425 from AFritzMulti/master

[MTS_GAMBIT] Modified PinNames.h and device.h for Gambit platform