How should Turbo Navigator expose underlying delegate callbacks?

[joemasilotti]

I sort of hinted at this in #62 but wanted to bring up a bigger discussion on the same issue.

Turbo Navigator is the SessionDelegate of each Session it manages because it needs to handle session(_:didProposeVisit:) to visit pages. It also provides sensible defaults for error handling, opening external URLs, etc. via a protocol extension. This gives developers the option to override which, if any, of these function they want to handle with custom logic.

However, not all of SessionDelegate is currently exposed. For example, I just found a need for sessionDidFinishFormSubmission(_:).

Should TurboNavigationDelegate expose all of the functions from SessionDelegate?

At first I thought that it definitely should. But then I started to wonder if we purposely shouldn't and provide some higher level API. Perhaps never even expose Session to the developer when using Turbo Navigator.

I ask the same question in #62 where Turbo Navigator assumes the role of the WKUIDelegate to handle confirmation dialogs. Should it also expose all functions of that protocol to the developer?

@olivaresf and @jayohms, I'd love your feedback on this. I feel like this is the last big question before I can open an upstream PR into turbo-ios.

[joemasilotti]

A path forward was figured out in #74.