Add Configuration Builder (and tests)

[jkmassel]

What?

Android uses a configuration builder which is much cleaner around mutability. This PR adds a configuration builder to iOS as well.

Why?

The configuration has concerning mutability – it should never change after it's created because it's injected at the start. Once it starts being consumed, changes to it don't apply elsewhere, so by making it immutable it's harder to use it wrong.

How?

Builder pattern

Testing Instructions

Covered by new unit tests.

[dcalhoun]

At a high level, this makes sense to me. Solid improvements—thank you! Testing the Demo app worked as expected.

This is likely already understood, but building WP-iOS with these changes fails currently. Before merging this, we should open a sibling PR updating the WP-iOS implementation.

That said, I wanted to address the following:

The configuration has concerning mutability – it should never change after it's created because it's injected at the start. Once it starts being consumed, changes to it don't apply elsewhere, so by making it immutable it's harder to use it wrong.

It's not entirely true that mutations do not have an impact at the moment, because we explicitly rely upon mutating the configuration to set the editor settings and start the editor after the host app fetches the settings.

I am quite confident that code could/should be refactored to be less complex. There are a couple of nuances to consider:

1. We "warm up" the editor on the My Site tab with an empty configuration;
2. Within init, we initialize the editor configuration and view controller;
3. And within viewDidLoad, we display an activity indicator and fetch the editor settings.

These nuances could likely be refactored to embrace immutable configuration while retaining the necessary loading sequence.

[jkmassel]

@dcalhoun – I broadly agree with your comment. IMHO having two methods on the editor like init and updateConfiguration both of which take an immutable configuration would make a ton of sense, and would make it clear that simply updating the configuration object doesn't cause the underlying editor to change in any way.

I'm happy to leave this PR with you, feel free to do with it what you think is best!

[dcalhoun]

@crazytonyli in addition to help with wordpress-mobile/WordPress-iOS#24662 (comment), I welcome your review of these changes now that I've rebased it atop the latest trunk branch. Thank you!

[dcalhoun]

@jkmassel unfortunately, this is a breaking change. Would you be willing to resolve the incompatible types and finish the WP-iOS integration? Alternatively, we could revert this change for the time being.

[dcalhoun]

@jkmassel I'll also note that GBK cookie configuration was removed from iOS in #157. I see that fc28a0a re-added iOS cookie configuration.

We should either remove cookie configuration again or finish reinstating it—ensuring we set them for the WebView and updating the WP-iOS integration.

Currently, WP-iOS relies upon the shared global cookie jar used by the WebView. GBK's cookie logic clears that out when launching its own WebView. We'd need to update WP-iOS to address this.

[dcalhoun]

@jkmassel it looks like this also reinstated the WebView globals removed in #172. I suggest we remove that too. It is now unused.