Upgrade to TimeZoneInfo usage so that all builds work and are better.

Microsoft recommends to use TimeZoneInfo instead of TimeZone for all recent
versions (starting from 3.5) of the .NET, plus this is the only class
available in non-mainstream flavors of .NET (like Silverlight),
so why not use it.
Also update the assembly version of the SL5 build of ServiceStack.Text.
Merge pull request #336 from ddotlic/master

Fixed SL5 build, but also other builds (please see comment below). Should be painless to integrate this. Also, please let me know next time you want to push a new NuGet build so that I can update SL5 binaries, thanks!
pre-INCR to v3.9.49 - setup for vNext
INCR to vNext v3.9.50
Non-numeric enums would be padded with double quotes. Added test in AdhocModelTests.cs and fix in JsonTypeSerializer.cs
Merge pull request #339 from tstade/StringEnumsDoubleEscaped

Fix for Issue #335 (double quotes for string enums to json)
Updated Silverlight to the latest code - 3.9.50.

Not superfluous, the previous version was broken. One user even reported it,
but we mistakenly did not test the released version but the (at the time)
current version of the source. For reference, the broken version - still on
NuGet - is 3.9.44; don't let this version fool you, SL5 build lag behind the
official build number so 3.9.49 includes SL5 binaries 3.9.44.
The crash happened in ServiceClientBase's constructor due to the misuse of
the CookieContainer.
Current code works fine, let's update SL5 build and update NuGet...
Merge pull request #341 from ddotlic/master

If possible, please push a new version to NuGet - see below, currently published version is broken (I am available for more info)
INCR for vNext to v3.9.53
Fix bug regression re-added in commit cb76ac
INCR to v3.9.54
Add a JsConfig.AssumeUtc option

Add an option to assume that DateTimes that have a Kind of Unspecified
are assumed to be Kind.UTC
Merge pull request #343 from niltz/master

Add a JsConfig.AssumeUtc
Support deserializing '0' and '1' for boolean values
fix test
Changed default behaviour of TryToParsePrimitiveTypeValues to always parse numeric types as either decimal, float or double.

This IMO is the safest choice as you shouldn't get any issues down the line working with decimals.
It is also the what I would expect from json.
Added config value TryToParseNumericType to allow the 'best' type to come back as per expected current behaviour
Added unit tests around behaviour new and existing behaviour
Reverted some changes from commit 9e8fd8e0091237a52c28af9f925c5edc225c837a to fix behaviour for
numeric type matching (looks like all unsigned numbers will be ulong)

Fixed issues raised in:
http://stackoverflow.com/questions/17368027/override-parseprimitive-in-servicestack-text
http://stackoverflow.com/questions/13716838/how-to-get-servicestack-to-serialize-deserialize-an-expando-object-with-correc
Merge pull request #347 from antonydenyer/TryToParseNumericType

TryToParsePrimitiveTypeValues numeric values default to decimal
Added RouteValueDictionaryTests.cs to test deserialization
Merge pull request #348 from jgeurts/master

Added test for deserializing RouteValueDictionary properties
INCR to v3.9.55