Support implementing Symbol-based EcmaScript protocols like Iterable

[justjake]

This adds a set of features that allow Swift developers to implement protocols using Symbols, like Iterable:

• Add helpers to NodeSymbol to access well-know symbols like Symbol.iterator, or the global symbol registry like Symbol.for("user.land.protocol").
• @NodeName(replacementName) renames members exposed with @NodeClass + @NodeProperty or @NodeMethod. To implement a symbol-based protocol, pass the symbol as the replacementName.
• Implement NodeIterator class to support the Iterable protocol. An example iterable is included in an integration test.

Individual commits have some more details.

Discussion points:

• Should the renaming functionality @NodeName be better as a parameter for the existing @NodeMethod / @NodeProperty macros? It was easier to implement as a new macro for me because I'm new to Swift.
• I avoided using macros to implement NodeIterator since I didn't see other uses within the library. Should I convert that class to a @NodeClass macro? Since there's only one method exposed, it's not much difference in code size in this instance.
• The NodeIterator class is used for supporting Swift developers writing Iterable classes to Node, not for consuming Node iterators in Swift, although that could also be useful as well. Should this implementation do both? Or is this kind of thing out of scope for the node-swift library?
• Code style: I tried to follow four-space indents as best I could. Is there an auto-formatting setup you use? My editor tried its best to really mess things up, and it would be easier to contribute if there was some swift-format or swiftformat tool set up.

[kabiroberai]

hey @justjake, thanks for the PR! Just wanted to let you know that I've given the code a first pass and these look like great changes. I'm a tad busy right now but I'll leave feedback asap, hopefully over the coming week. In the meantime, do you mind splitting up the @NodeName macro into a separate PR? I think that's a slam dunk addition as-is (modulo some nits) and I'd be happy to merge that separately.

NodeIterator also seems very useful but it warrants some thought about whether we should introduce additional layering into this package. So far NodeAPI has largely aimed to replicate the C Node-API surface 1:1. There's definitely room for ergonomics on top of that, but I wonder if we should keep those in a separate module within the package. That could be a good place to move stuff from Sugar.swift et al too.