Support symbols for fields and functions of exported structs

[RunDevelopment]

Motivation

Certain JS protocols require symbols to identify a certain method or field. E.g. for #4142, we need to use Symbol.iterator to define an iterable object.

Proposed Solution

Support the syntax #[wasm_bindgen(js_name = Symbol.name)] to define use symbols instead of regular (string) identifiers for struct fields and functions. A different syntax to identify symbols may also be used, e.g. @@name.

Whatever syntax is used, I think the syntax should be made exclusive. So current code using js_name = Symbol.name (or whatever syntax is chosen) should fail to compile for non-class member bindings. Example:

#[wasm_bindgen(js_name = Symbol.iterator)] // error
fn foo() { }

#[wasm_bindgen]
struct Foo;

#[wasm_bindgen]
impl Foo {
    #[wasm_bindgen(js_name = Symbol.iterator)] // ok
    pub fn iterator(&self) -> js_sys::Iterator { todo!() }
}

Alternatives

1. Don't support symbols via #[wasm_bindgen] and rely on reflection. This is quite painful.
2. Add a new option, e.g. js_symbol, separate from js_name for symbols. I don't think this is a good idea. A symbol is intended to be a unique name, so using js_name makes sense.

Additional Context

I'm willing to make a PR, but want to know whether my proposed solution is acceptable.

[daxpedda]

2. Add a new option, e.g. js_symbol, separate from js_name for symbols. I don't think this is a good idea. A symbol is intended to be a unique name, so using js_name makes sense.

How is the uniqueness of its name related to the js_name attribute?

---

This will collide with #4118, so we need a blacklist for those kind of names.

[RunDevelopment]

2. Add a new option, e.g. js_symbol, separate from js_name for symbols. I don't think this is a good idea. A symbol is intended to be a unique name, so using js_name makes sense.

How is the uniqueness of its name related to the js_name attribute?

Not at all. I just meant to say that symbols act as names/identifiers to justify reusing js_name. They just happen to be unique.

This will collide with #4118, so we need a blacklist for those kind of names.

Good point. We should probably disallow user-defined Symbol.dispose methods. I mean, it would be weird if obj.free() and obj[Symbol.dispose]() did different things, despite having the same logical purpose. Though I'm not sure if there might still be use cases for custom Symbol.dispose methods.

[daxpedda]

I'm not qualified to solely approve this. So unless we get more qualified input, going ahead with some sort of experimental switch would be fine with me as well.

Otherwise this LGTM.