WIP: Upgrade oscpack to 1.1.0

This is for issue #1911.

I tried to modify oscpack as little as possible to make future upgrades as smooth as possible. 
So far I only changed the filenames in ip/win32. 
I guess we _still_ need the respective ifdefs like before, for the IDE projects which don't use make, @arturoc?

those files are excluded with a pattern in `addon_config.mk` on makefile-enabled platforms, does this work the way I did @bakercp @arturoc? (i.e. exclude in common, re-include on windows platforms?) It would be nice because then you only have specify two platform sections.

The [osx Nil fix](1d1ed0f306dfb68d28575bad6de0741350034fd5) is apparently handled within oscpack now, so no modifications for that necessary.

The [host endianness detection](https://github.com/openframeworks/openFrameworks/commit/8ecd5aa758a62e3221f580e307fd267fa65f87a1#diff-2) should also [be fixed within oscpack now](https://code.google.com/p/oscpack/source/detail?r=87#), but would probably good to try.

The reused ports and broadcasting functionality are [included in oscpack now](https://code.google.com/p/oscpack/source/detail?r=86) (and off by default). I have wrapped those in private functions (if wanted we can make those public), and added optional parameters to the relevant constructors. I have chosen to leave both off by default (and documented some details), since all the implications are not really clear, and people who need this can now easily enable it.

Open question:
* I'm not sure why https://code.google.com/p/oscpack/source/detail?spec=svn86&r=70 doesn't have more impact, i.e. compile warnings? I'm compiling on 64bit currently, maybe that is masking it?
* Does the `addon_config.mk` work the way I did it?
* Do we still need the platform ifdefs around the win/posix IP implementation?

So far it looks good (the OscChatSystemExample works flawlessly), although I can't test cross-platform and windows IDEs. Would appreciate feedback on the implementation and thorough testing, as I only have a quite superficial understanding of the ofxOsc implementation intricacies.
@kylemcdonald @ofTheo @arturoc @damiannz

Closes #701