Do not use DictionaryKeyPolicy on deserialization

[JamesNK]

re: https://github.com/dotnet/corefx/issues/38840#issuecomment-506888027

DictionaryKeyPolicy is being used for deserialization as well as serialization. I'm not sure when this decision was made, but I think this has a number of problems:

1. JsonNamingPolicy (and JsonNamingStrategy in Json.NET) are designed as a one way operation. There is only ConvertName on the type. There is no pair of ConvertTo and ConvertFrom methods. That is because you can't reliably undo PascalCase to camelCase or underscore_case.

2. It is common for people to reuse the same serializer options for both serializing and deserializing. When using the policy is used in both directions, calling the same JsonNamingPolicy on an incoming dictionary key will at best do nothing, or at worst double convert. For example, a naming policy that HTML encodes a string will now HTML encode it in both directions: "J & NK" -> "J & NK" -> "J & NK"

3. It is inconsistent. DictionaryKeyPolicy is called during deserialization but PropertyNamePolicy is not.

4. What is the user scenario for this? The naming policy with serialization is useful for people who want dictionary keys to be camel cased, but what purpose is there to run the policy on deserialization? You can't undo camel case back to pascal case so it's not that. I ask because this is a feature that has never been requested in Json.NET.

[layomia]

cc @steveharter, @pranavkm, @rynowak, @ahsonkhan

[steveharter]

Offline discussion recap: do not use naming policy on deserialization. The reason is primarily for performance since the scenario where this is useful (normalizing incoming dictionary keys that have mixed casing) is an edge case with workarounds (creating a custom converter for dictionary or instantiating collection case-insensitive from POCO ctor).

On (1) and (2) above -- the naming policy is one-way and is expected to be idempotent, so running it on deserialization and again on serialization should be fine.
On (3) above - consistency not really a factor since the two cases (property names and dict keys) are different; the property name policy does actually run during serialization and deserialization in a way -- the first time the POCO type is serialized or deserialized the policy executes against the POCO property (not the JSON) and then caches the value which is used during deserialization to match up against the JSON and during serialization to write the property name.
On (4) above - the scenario is normalizing incoming dictionary keys that have mixed casing; again an edge case with workarounds.