feat(iOS): Add automatic Date serialization to bridge communication

[ikeith]

Currently, WKWebView will automatically translate JavaScript Date objects to NSDate/Date objects when sending data over the bridge from JavaScript -> Native. While this might be helpful it is potentially unexpected, and it is inconsistent with Android where the Dates are turned into strings. Dates are not handled at all when sending Native -> JavaScript and including a Date in the result dictionary will cause an exception to be thrown during serialization.

So, this branch does 3 things related to Dates and returning the result of a plugin call.

1. It serializes Dates in plugin calls during type coercion. This operation is not performed for Cordova plugins to preserve backwards compatibility. In addition, a plugin can opt-out of the new behavior by setting its shouldStringifyDatesInCalls property to false.

2. It serializes Dates in result dictionaries automatically. A date in will result in an ISO 8601 string out in both directions now. Since the previous behavior was an error, there is no compatibility concerns and plugins can opt out of the serialization by transforming the dates before inserting them into the results.

3. It refactors some of the calling objects in service of 2, as well as to prepare for Codable support in the future and paying down tech debt:

   • The declaration/implementation of CAPPluginCallResult and CAPPluginCallError have been moved from Obj-C to Swift. This keeps the same Obj-C interface but allows them to use new swift types internally.

   • PluginCallResult is a new Swift enum to wrap result dictionaries that can be extended to support additional types (such as Encodable objects in future work).

   • Multiple typealias types have been consolidated.

   • JSCall, JSResult, and JSResultError classes have all been refactored into internal immutable structs. Since the methods that use those objects are all internal, it made no sense for them to be public. That is technically a breaking change but there is no reason for external code to be referencing them.

   • Some of the surrounding code has been cleaned up to become more idiomatic and to remove force-unwraps and unused code.

Closes #4160

Documentation update: ionic-team/capacitor-site#207

[theproducer]

This looks good! However, the new default behavior breaks some things in local-notifications based on my tests (and potentially other core plugins). Should we hold off on merging this in until we review / fix any breaking changes in our plugins, or do it now and fix any issues as they come up (hopefully before the next beta)?