"Interface of component" is defined over `expose` and `bindings`, which is confusing

Nobody has claimed this yet.

We once had the design goal of `expose` describing the whole interface of a component. "Interface" in this sense encapsulates two things in my opinion:

1. All functions that the model of a component brings that should be callable from the outside.
2. All functions that the model of a component **changes**, when compared to the implementation in the original morph class of the good old `Morph` or whatever the `type` of the component is.

I recently learned that this assumption was always broken, due to the `override` parameter of bindings. However, the implication of this really dawned on my only when merging #1593, where it is very obvious that there are now `keybindings` and `commands` that come from inside of the model without them being listed in `exposed` any more.

We briefly discussed two solutions, and I could live with both of them. However, they are also not mutually exclusive:

1. @merryman proposed to just get rid of the `override` option in `bindings` and move that over into `expose`.
2. An alternative approach could be to revisit the original goal I had in mind with the above concept of an "interface", which is mainly concerned with the affordance of reading code and using components. This could also be tackled by visually indicating methods that comprise the interface in a graphical way inside of the systems browser. This could for example be achieved with a different icon inside of the muller-columns or a colored icon.

Review the current handling of component expose and bindings, especially the bindings override option, and compare the keybindings and commands behavior discussed in #1593. The issue presents multiple possible directions, so work would first require an agreed design: moving override into expose, revising interface semantics, or adding graphical indication in the systems browser.

Written by the indexing model from the issue text.