Make it illegal to use the word 'widget' anywhere

[louh]

The term "widget" was introduced early on to refer to any interactive UI that dynamically adjusts values in Tangram YAML. Over time, as the complexity of this functionality evolved, it has grown into a super-generic umbrella word that refers to different kinds of components. It's such an easy word to use, but as it becomes easier to say sentences like "Let's put in a color widget" or "vec3 widgets are broken", the word "widget" itself is an abstraction over the specific implementation details which limits understanding of the actual problems or functionality in question. Currently, the word "widget" can be used to describe any of the following:

1. An in-line bookmark (a CodeMirror term), something that is embedded at a position in the document, but is not part of the document's content. (Note that CodeMirror itself uses the property name widget to refer to a DOM element that can represent the bookmark, and at the same time also uses widget to refer to other methods, further adding to the confusion, but this is likely where we first started using the word.) In Tangram Play, we use bookmarks by placing them immediately to the right following a YAML node's value. They may visually represent the value (as in the color picker or a true/false checkbox) or are a UI element that affords additional interactivity (as in a dropdown). They can be clicked on and responds with additional functionality so users can adjust the value dynamically. Sometimes, to differentiate these bookmarks from other widgets, we use the term "widget mark" or "widget bookmark."
2. The UI component which can appear in response to clicking on an in-line bookmarks. We have in the past also called them "pickers," as in "color picker," because they exist to pick a value and disappear when the user no longer wants to do that. We have also sometimes referred to them as a "modal", although they've never been true modals (a dialog box which prevents interaction with the main application until a user expressly confirms or cancels the action). This component is usually a standalone DOM element which is seen to be floating above the interface, as in the case of an element which exists outside of the editor can be repositioned. However, it can also be attached to its location in the editor, as in a dropdown component, which are positioned inside the editor's DOM hierarchy.
3. Not all UI components that adjust values are created by clicking on an in-line bookmark. In GLSL (shader) blocks, for instance, these UI pickers are created by clicking on a value in the code itself, rather than on any specific DOM element created for that purpose. These are currently called "widget links" to differentiate them from other sorts of widgets because of the link-like nature of the values being clicked on. The "links" themselves have no special appearance. Similarly, a color picker modal is created when clicking on a color palette item, which is not part of the editor at all, but floating UI that exists outside of it (although it interacts with the editor).

Let's recap why this is a problem:

• Widgets might be visual elements embedded in the document.
• Widgets might be interactive text in the document that spawn other widgets when clicked.
• Widgets might be a DOM element that is floating outside of the editor but shown when clicking on other embedded widgets or document text.
• Widgets might be a DOM element that is embedded in the document but shown when clicking on other embedded widgets.
• Widgets might be a DOM element that is floating outside of the editor and shown by clicking on other UI outside of the editor.

These are all widgets or use the word "widget" in its name.

This is just an effect of a word growing to be too all-encompassing over time because we didn't carefully watch our use of it. My fear is that it is too late for us to continue using this word without giving us an "out" and falling back to its former abstractness. I propose that we carefully consider what we want to call each of things we currently refer to as "widgets" (it doesn't have to group those three categories above, but that would be a useful starting point) and start being much clearer in our code, in our documentation, and in our issues what we are referring to. To enforce this, we should include a test suite which will throw a warning or even fail the build entirely if we attempt to re-introduce "widget" into the codebase

My goal is to re-introduce clarity over lazy word usage. Let's discuss.

cc @irealva @patriciogonzalezvivo @bcamper