Make type conversion a first-class concept when parsing options

[Andy Wilkinson]

Feature Request

Is your feature request related to a problem? Please describe

As described in #205, there are some type-safety problems with Option. A simple fix would be to return Object when retrieving the value of an Option, but that would leave the problem of knowing how to turn a String parsed out of a URL into the type that the Option requires.

Describe the solution you'd like

Having discussed this with @mp911de, if an Option held a Class<T> for the type of its value, ConnectionUrlParser could then be configured with a BiFunction<Option<?>, String, ?> that can convert a String into the required type for a given option.

Describe alternatives you've considered

An alternative would be to keep conversion local to a specific option with a method that's something like this:

<T> Option<T> valueOf(String name, Function<String, T> converter)

The option itself would then be armed with a converter function that can turn a String from URL parsing into the required type. This provides more flexibility as each option can decide on how any conversion is performed. However, this creates the possibility for inconsistent conversion across different options. It also exposes something that's really a URL parsing concern in the API of Option. Plugging a conversion strategy into connection URL parsing would place the solution next to the source of the problem.