Refactor/option delegated properties

[citizenmatt]

This PR introduces strongly typed delegated properties to get and set option values. Options of primitive type are implemented as read/write properties with native types, e.g. String, Int and Boolean, which makes it very easy to get/set an option value from code. String list options are represented as a read only property of type StringListOptionValue.

E.g.:

val ignorecase: Boolean = injector.globalOptions().ignorecase
injector.options(editor).selection = "exclusive"
val scrollOffset: Int = injector.options(editor).scrolloff
val clipboard: StringListOptionValue = injector.globalOptions().clipboard

The options are accessed via injector.globalOptions() and injector.options(editor) functions, similar to how OptionsValueAccessor was used. The OptionsValueAccessor class has been removed in favour of the strongly typed properties. The VimOptionGroup.setOptionValue function can be used to set an option found at runtime via VimOptionGroup.getOption.

The StringListOptionValue type implements List<String>, so the values can be iterated, or a specific item can be checked with in or contains. It also implements the appendValue, prependValue and removeValue helpers to make it easy to modify the string list. The underlying string is available through the value property.

String list options can be used like:

val hasIdeaput: Boolean = injector.globalOptions().clipboard.contains("ideaput")
injector.globalOptions().clipboard.prependValue("ideaput")
if ("ideaput" in injector.globalOptions().clipboard) { ... }

// Java
for (String s : injector.globalOptions().getMatchpairs()) { ... }

[citizenmatt]

I'm not too keen on this, but we can't upcast VimOptionGroup to IntelliJ's OptionGroup because we re-implement the VimOptionGroup in tests. An alternative would be to create an IjVimOptionGroup interface to access IntellIJ specific options, and have the test class also implement this interface. What do you think?

[AlexPl292]

Do you mean that we reimplement it by OptionsTracer? If yes, I'd comment out OptionsTracer as this should not affect the architecture decisions.

[AlexPl292]

This looks good to me! But still, I'd love to see some historical notes like:

• We used to have "access by name" approach, but we consider this as a better solution (access by field). Please don't switch back to "access by name".
• We used to have "string as list" approach, but we consider this as a better solution (StringListOption class). Please don't switch back to "string as list".

Also, I'd love to see some small instructions on how to add a new option. Like what classes should be affected by that.

[lippfi]

Everything is so clean now, thank you!

[citizenmatt]

@AlexPl292 Just pushed some minor updates to address comments