Configuration cleanup

[Roemer]

The configuration has interfaces but almost everywhere are the concrete classes being used.
I'd like to remove all the singletons from the configuration classes and propose to use a Locator where the concrete class can be overwritten.
In this PR in it's current state you see this implementend with the WebBrowserConfiguration.
Please give me feedback on what you think before I do the same with ScreenObjecs configuration and Core und UIItems configuration.

[JakeGinnivan]

Playing devils advocate. Why do we even need the interfaces?

Let's make configuration static and remove the interfaces entirely if we are going to make the breaking change?

[JakeGinnivan]

propose to use a Locator where the concrete class can be overwritten

What does that give us?

[Roemer]

I like the possibility to have different configuration sources. By default, White provides the one from the App.config. But someone might want to use configurations in a textfile or a database or dynamically generated.
We could also think about having the configuration class static with just the value getters/setters and then make configuration readers with interfaces and provide the appconfigreader which fills the static class there.

[Roemer]

propose to use a Locator where the concrete class can be overwritten

What does that give us?

Static access to a class of a certain interface without exactly knowing the class.

[Roemer]

I added an alternative version (less interfaces) with RepositoryConfiguration.
This is the configuration instance (independent of how it was read). And then there are ConfigurationReaders (currently only the AppConfigReader) which allows to fill configuration instances with some logic. What do you think about that?

[Roemer]

Any feedback on the last commit (except the test failures)?

[dpisanu]

Looks ok from my point of view.
I like the move to only going by the Interfaces and not the concrete Class Implementations.

[Roemer]

So you prefer the one in WebBrowserConfiguration? One downside there is that each implementation of IWebBrowserConfiguration has to set it's own default values and have it's own implementation of how it handles the values of the settings.

[dpisanu]

it's a question of how much flexibility do you want to provide.
what should be avoided though is giving the tool and flexibility but then doing some default 'infejction' because flexibility causes overhead.
this really really is a decision above my paygrade :p

[Roemer]

I think the flexibility we need is in how the configuration values are read and not how to get the values once they are read. That's why I'd currently prefer the 2nd version (from the RepositoryConfiguration).

[Roemer]

This is superseeded with #380