feat: duplicate navigation related APIs to contents.navigationHistory

[alicelovescake]

Description of Change

This PR refactors and duplicates navigation related APIs to contents.navigationHistory. Follow up to previous PR #41577 where a new navigationHistory property is created on web contents.

This PR duplicates and exposes the following API for consistency and clarity:

• canGoBack
• goBack
• canGoForward
• goForward
• canGoToOffset
• goToOffset
• clear

Added related tests and documentation.

For backwards compatibility, the above APIs can still be directly accessed from webContents.

Checklist

• PR description included and stakeholders cc'd
• npm test passes
• tests are changed or added
• relevant documentation, tutorials, templates and examples are changed or added
• PR release notes describe the change in a way relevant to app developers, and are capitalized, punctuated, and past tense.

Release Notes

Notes: Added the following existing navigation related APIs to webcontents.navigationHistory: canGoBack, goBack, canGoForward, goForward, canGoToOffset, goToOffset, clear

[codebytere]

Codewise this looks great to me - the only outstanding question here is what (if any) timeline we'd want to consider targeting for deprecation of the old methods. Our options I would say are:

1. Merge this as is and support both for the medium-term future, deprecating the old approach in a handful of versions and removing a few after that
2. Deprecate now to indicate that developers should look to use the new code where possible but leave in for a good long time, no specific removal date
3. Deprecate and remove in the next few targeted cycles

My personal approach would probably be #2 but I think any are reasonably justifiable. I do think we should decided on one before merging though! Thoughts (cc @MarshallOfSound)?

[samuelmaddock]

I'd be in favor of adding deprecation warnings now (2) as to give developers and library authors the most time to migrate.

[alicelovescake]

Thanks for the feedback! @codebytere @samuelmaddock

I updated the PR with _Deprecated_ in the docs to let developers know to use the new api.

In the future, when we are ready to officially deprecate, I can:

• update docs/breaking-changes.md
• move the api to internal-electron.d.ts

Let me know if there is anything else I can do for deprecation warnings for this PR!