Resolves #127
Relates to / resolves #1722
Supersedes #1035

Currently Gson uses String.valueOf for Map key serialization and the regular TypeAdapter.read method for deserialization. This is often not symmetric, preventing serialized data from being deserialized again, and is also not easily customizable by the user.

This pull request adds the TypeAdapter methods createPropertyName(T) and readFromPropertyName(String). These allow the user to define how values should be converted to a property name and how it should be converted back. The default implementation of using String.valueOf was kept for backward compatibility.
These methods have the following advantages:

• Users can customize how conversion to property names should happen; and for classes where this makes no sense can also prevent it by throwing an exception
• Custom type adapter factories for Map-like types can uses these methods as well, having a well defined way to convert Map keys
• For these cases where Gson is currently not behaving well for Map keys (e.g. Deserisation fails with when using null numeric primitives as map keys #1385 or Gson Serializetion Bug in Enum Map #1920) users can at least provide their own type adapter which properly performs the conversion delegating to the existing adapter. An example for this can be seen in the added test method MapTest.testCustomEnumMapKeyConversion().

It might have been ideal if Gson added such methods in the past already so only types for which conversion to property names makes sense would have opted-in into the conversion. The current opt-out situation (especially with String.valueOf usage) is error-prone because users convert values to property names for which this was never intended or considered.

The implementation of this pull request allowed removing the error-prone promoteNameToValue method (see also #1768). This comes at the cost that the default implementation of readFromPropertyName creates a new JsonTreeReader wrapping the name as JsonPrimitive. This is not as performant, loses information about whether the original JsonReader was lenient and about the JSON path. The lenient setting is probably not that important because it would have only been used when the name was read as non-finite double. The missing JSON path can be worked around by having the caller catch the exceptions and add additional context, such as the JSON path. In general it is recommended that adapters which do want to support property name conversion should override readFromPropertyName for better performance.
An alternative would have been to use the signature readFromPropertyName(JsonReader); this would solve these issues and would also allow streaming reading of the name (as proposed by #1604; though most likely rarely / never needed), but would require keeping promoteNameToValue and I think it would reduce usability because readFromPropertyName will only be called for names, so only nextName() (and a few other methods) can be called; all other ones would always throw an IllegalStateException due to token mismatch. The approach of only passing a String to the method seems less error-prone and easier to use to me.