…d` as `unavailable`

Follow up to #2449.
This is step 2 of 3 towards getting rid of `userCancelled` in purchase results.

After #2449, `ENABLE_CUSTOM_ENTITLEMENT_COMPUTATION` builds no longer send `userCancelled` `true` for cancellations, and instead throw `ErrorCode.purchaseCancelledError`.
To avoid users detecting cancellations looking at this property, it's not deprecated.

To achieve that, I converted the `tuple` into a `struct`. This also required moving the affected `purchase` methods from `PurchasesType` to `PurchasesSwiftType`, but that's an implementation detail.

The public API remains _mostly_ unchanged, with the only caveat that it's no longer possible to destructure the result tuple, so:
```swift
let (transaction, customerInfo, cancelled) = Purchases.shared.purchase(...)
```
Needs to become:
```swift
let result = Purchases.shared.purchase(...)
```

I updated the API tester to reflect that, as well as checking the properties of `PurchaseResultData`.

As it's documented in #1910, completion block APIs already did send both `userCancelled` and the `error`, so we don't need to change those.

This paves the future for a full deprecation, where we mark it `deprecated` for normal builds as well, and change the behavior regardless of the `DangerousSettings`.

…cancelled purchases (#2449)

Fixes SDK-3088
Supersedes #2447

Thanks to @tonidero for doing most of this.

Note that it's currently impossible to test this for SK2, so we only
have SK1 tests (we have a Radar for that).

The next step will be to deprecate the current API to remove the
`userCancelled` property and make this the new behavior.
See also #1910 for an explanation of the different return values of the
purchase APIs.

Follow up to #2597.
When we implemented #2449 we couldn't add tests for that different in behavior. This can be reflected with this test now.

…ons (#2849)

Follow up to #2597.

When we implemented #2449 we couldn't add tests for that difference in
behavior. This can be reflected with this test now.