[CHNL-16564] update script and message handling

[ab1470]

Description

This PR makes some updates to the KlaviyoWebViewModeling protocol, all conforming ViewModels, and the KlaviyoWebViewController. We will need these changes in order to handle the javascript messages that the in-app forms emit.

With this PR, I'm decoupling the javascript that gets injected into the WKWebView from the message handlers that get injected. This will allow us, in a future PR, to tell the WKWebView to listen for messages from the KlaviyoNativeBridge, even though we aren't injecting a script with the same name.

Check List

• Are you changing anything with the public API?
• Have you tested this change on real device?
• Are your changes backwards compatible with previous SDK Versions?
• Have you added unit test coverage for your changes?
• Have you verified that your changes are compatible with all the operating system version this SDK currently supports?

Manual Test Plan

1. I've tested this using Xcode previews and with the iOS test app

[ajaysubra]

Some minor questions but looks good to me

[ajaysubra]

Do we need this since @evan-masseau mentioned that he doesn't think we may end up injecting scripts on the native side?

[ab1470]

yes, I'd like to leave it for 2 reasons:

1. It gives us flexibility to easily inject scripts if/when we want to. Evan said on Friday that he suspects we may want/need to do that in the future
2. It's optional, so if we decide we're not going to inject any scripts we can simply set that value to nil.

The way I built this, the KlaviyoWebViewController is flexible and can be reused when injected with different ViewModels, as long as the VMs conform to the KlaviyoWebViewModeling protocol. So we can, for example:

• instantiate one KlaviyoWebViewController using a viewModel WebsiteWithInjectedScriptsViewModel
• instantiate another KlaviyoWebViewController using a viewModel WebsiteWithoutInjectedScriptsViewModel

[ajaysubra]

Is this the view model that we'd use to present a Klaviyo form?

[ab1470]

No, this is just for dev/testing purposes right now. Whatever we put into production for handling a Klaviyo form will be a different VM that confirms to KlaviyoWebViewModeling. That protocol will mandate that we implement all properties and methods that the KlaviyoWebViewController depends on