fixes to the return types of several Node helper extension methods

[devoncarew]

• fixes to the return types of several Node helper extension methods

When trying to port DartPad to package:web, I noticed that the Node.clone() extension method had a return type of void, which made it hard to use. This PR updates clone and append to have the same signatures as they have in dart:html.

As an aside, when using code completion for a Node element, I see completions for both append and appendChild, and clone and cloneNode. Two are from extension methods and two are generated. It's not clear to me as a user which methods I should be using, what the differences are, or why there are multiple options. Perhaps we should plan to deprecate the extension methods which are just there to ease porting from dart:html? Where there are trivially the same generated methods available, and the extension methods don't add any usability improvements?

---

• I’ve reviewed the contributor guide and applied the relevant portions to this PR.

Contribution guidelines:

• See our contributor guide for general expectations for PRs.
• Larger or significant changes should be discussed in an issue before creating a PR.
• Contributions to our repos should follow the Dart style guide and use dart format.
• Most changes should add an entry to the changelog and may need to rev the pubspec package version.
• Changes to packages require corresponding tests.

Note that many Dart repos have a weekly cadence for reviewing PRs - please allow for some latency before initial review feedback.

[srujzs]

Perhaps we should plan to deprecate the extension methods which are just there to ease porting from dart:html? Where there are trivially the same generated methods available, and the extension methods don't add any usability improvements?

cc @sigmundch

I agree! I think while this might make migration slightly easier, it'll complicate how users use these types. These members are simple enough as well that we can remove them. If you want to remove them in this PR, that's fine by me.

[devoncarew]

If you want to remove them in this PR, that's fine by me.

For this PR, I just deprecated them; that'll let us remove them in a future major release.

[srujzs]

Sounds good, thanks Devon!