feat: create driver option classes

[titusfortner]

Change list

• Added MobileOptions, IOSOptions and AndroidOptions for easier capability generation

Types of changes

• No changes in production code.
• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Details

Replacement PR for #1319

I've decided that it is too much of a pain to implement all of the options for Android & iOS.
All the subclasses will do is create the correct platform name. Any platform specific values will need to be added by a user with setCapability().

Again, the reasoning for this approach is it is similar to how Selenium encapsulates the capabilities for the driver specific options, and this will be a better thing to encourage users away from using DesiredCapabilities when that class gets deprecated.

Also, should these be named IOSOptions and AndroidOptions or does "Mobile" need to be in there?

[mykola-mokhnach]

this option is not just mobile, but is also applicable to other driver, like for example the Mac OS or Windows one. I was also thinking about what we could do with these. Perhaps, it makes sense to extract such common options into an interface with default method implementations (aka java-like mixin) and add this interface into concrete option classes for different platforms?

[titusfortner]

Yeah, but of the 10 capabilities specified in the w3c, this is really the only one that applies to mobile, so I don't think it is worth spending time on the overlap.