Discussion: Properties vs. Attributes

Currently we have two interfaces that are somewhat similar:

`Properties` is used by the widget constructor and the `set` method on widget and widgetCollection. It describes a plain object where the key-value pairs are property name and property value to be set on the widget: `new MyWidget({foo: 'bar'})` or `myWidget.set({foo: 'bar'})` is the same as `myWidget.foo = 'bar'`.

`Attributes` is used by JSX elements, the new factory API, and - as for 3.7 - the `apply` method. It is a superset of `Properties`, which in addition to properties also can include listeners to be registered for a event matching in name:
`` or `Widget({onFoo: barListener})` is (almost) the same as `widget.onFoo(barListener)` or `widget.onFoo.addListener(barListener)`.

## Question:
Would it be a good idea to accept `Attributes` in places where `Properties` was used before? (Maybe even depreacate `Properties`.)

## Pro
I have seen it several times that `Properties` and `Attributes` are confused with each other, e.g. on coding components such as:

```js
class MyWidget extends Composite {
constructor(attr: Attributes) {
super(attr); // WRONG
}
}
```
Making e.g. the constructor accept `Attributes` would eleminate this.

## Con

Could cause even more confusion since, for example,
```
widget.set({onFoo: listener1});
widget.set({onFoo: listener2});
```
would in fact not register both listeners, but only listener2. [**That's how `apply` already works,**](https://docs.tabris.com/3.7/selector.html#compositeapply) and it's also in line with the really old [HTML event attributes](https://stackoverflow.com/questions/6348494/addeventlistener-vs-onclick)

## Potential Compromise
Another option would be to only accept it via constructor, not `set`. That would make the `asFactory` method less necessary, as the the only difference would really be that `new` can be omitted.