Introduce deprecation warnings to assist in migrating from OktaIdx 2.x

[mikenachbaur-okta]

Note: I can't see a decent way to unit test the unavailability of certain APIs without causing the test runner to blow up.

[mauricesharp-okta]

Is this for the 3.x version of the SDK?

There may be some deprecation notices missing for properties that moved classes and for modified type aliases. The notes I have are:

• IDXClient.Application -> Application (is this property private?)
• IDXClient.User -> Response.User (is this property private?)
• IDXClient.Message -> Response.Message
• IDXClient.Message.Collection -> Response.Message.Collection
• IDXClient.Message.Severity -> Response.Message.Severity
• IDXFormValue -> APIRequestArgument (value of a form field)
• Form.messages changes from IDXClient.Message.Collection to Response.Message.Collection
• Added struct IDXServerError that conforms to Error and LocalizedError

There're also other changes that can impact types and conformance:

• Authenticator adds conformance to Equatable
• Authenticator.State enum changes to Comparable from Int
• InteractionCodeFlow.Context changes from a class to a struct that conforms to Codable and Equatable
• Message conforms to Equatable and Hashable
• Collection conforms to Equatable and Hashable
• Remediation conforms to Equatable and Hashable

[mauricesharp-okta]

Other changes move functionality out of IDX to AuthFoundation including: Token, Credential, and OAuth2Client.PropertyListConfiguration. Someone updating from 2.x to 3.x won't know those are available unless we tell them.

Finally, there are changes to type aliases.

I found all these things out by updating doing a diff of 2.0.1 and 3.0.0, and by existing IDX code to use the new SDK.

[mikenachbaur-okta]

@mauricesharp-okta I tried going in that particular direction, but in the end it made Xcode's automatic fixes and error suggestions worse. The goal is to streamline the transition to the new APIs, so I kept that in mind. So adding proper support for codable/equatable/hashable just gets in the way since it's not necessary for the transition.

Though I could add availability attributes for those other classes that had their namespace changed.

[mauricesharp-okta]

Add anything you can without Xcode throwing a fit (or at least setting an ignore so it can scream quietly ;-)).

[mikenachbaur-okta]

I'm going to merge this as-is, because any "refactor" options Xcode provides don't work well with nested namespaces. e.g. IDXClient.Application doesn't properly refactor to Response.Application, since it tries to replace IDXClient with InteractionCodeFlow first.