Add a new 'unacceptableStatusCode' error case to WordPressAPIError

[crazytonyli]

Description

This PR is a follow-up to #658 (comment).

At the moment, when an API call returns an failure result (non-200 status code), the existing URLSession helper returns a Swift.Result.success case. After dealing with it a while, I find it too weird... So, this PR changed that by reporting a new WordPressAPIError.unacceptableStatusCode error upon unacceptable status code(non-200 by default, but it is customizable).

This PR introduces breaking changes, in terms of compile time backwards compatibility: swift-case statements on WordPressAPIError may fail. However, I don't think our apps/libraries actually have such statements.

Testing Details

See the updated unit tests.

---

• Please check here if your pull request includes additional test coverage.
• I have considered if this change warrants release notes and have added them to the appropriate section in the CHANGELOG.md if necessary.

[mokagio]

Only a non blocking naming suggestion

[mokagio]

How timely. I left a comment on a PR recently that introduced breaking changes, wordpress-mobile/WordPress-iOS#22320 (comment), asking to make them non-breaking with a reminder to update them when we have enough of a corpus of breaking changes to warrant the "effort" of updating WordPressAuthenticator as well.

This seems to be the case now 😄

[crazytonyli]

Followed up here: #678

[mokagio]

How do you feel about calling this decodeSuccess?

The motivation for this suggestion comes from looking at the usage in the unit tests:

        let result: WordPressAPIResult<Post, TestError> = await URLSession.shared
            .perform(request: .init(url: URL(string: "https://wordpress.org/hello")!))
            .mapSuccess()

Seeing that mapSuccess call with no argument was surprising as I'm used to seeing map-like calls taking passing a function or a closure.

[crazytonyli]

Renamed in cab530e.