* remove   from tag pill in edit mode
PR: fix missing space between edittemplate tags #3585 introduced an unbreakable space ...
The ` ` isn't needed and **causes problems**, if users copy&paste the tag text, because the "new" tag in the text input field now contains an space in front of the tag. This space invalidates the tag, so it doesn't function anymore.
see [comment in GG](https://groups.google.com/d/msg/tiddlywiki/RQEyqPQIZSM/uaU7lgJJAAAJ) .. I also had a problem like this some time ago, which costed me several hours of debugging.
* Update base.tid
* Update tag.tid
#4093 and #4100 are bundled in this PR
* qualified state-tiddlers for the tags input and fieldname + fieldvalue inputs
* newTagName, newFieldNameTiddler and newFieldValueTiddler variables defined in EditTemplate (all qualified through `qualify` macro)
* save-tiddler-actions macro in the EditTemplate (reused by the save-tiddler button)
* enter (configurable) in the fieldvalue field adds the field and sets focus to the next fieldname input
Edit:
* storyview="pop" for fields list
* make tag-picker add-button compliant with enter-actions
... the `$actions$` way throws a filter syntax error in some cases, the `<<add-tag-actions>>` way is more solid
* Update tags.tid
remove tag-picker-actions
Previously, it was not possible to deselect entries by editing the tiddler $:/generated-list-demo-state used in the final example of the SelectWidget docs
* add whitespace trim to advanced search button
* add whitespace trim to new tiddler
* add whitespace trim to new journal
* add whitespace trim to new image
* add whitespace trim to control panel button
* add whitespace trim to tiddler manager button
* add whitespace trim to language button
* add whitespace trim to palette button
* add whitespace trim to theme button
* add whitespace trim to storyview button
* add whitespace trim to timestamp button
* add whitespace trim to encryption button
* add whitespace trim to tag-manager button
"Sub-plugins" are displayed within the dropdown of their parent plugin.
This is a more elaborate version of #4109. It doesn't address dependent plugins (yet), this is just about grouping addon plugins under their parent.
* First pass at dynamic loading/unloading
* Show warning for changes to plugins containing JS modules
* Use $:/config/RegisterPluginType/* for configuring whether a plugin type is automatically registered
Where "registered" means "the constituent shadows are loaded".
* Fix the info plugin
The previous mechanism re-read all plugin info during startup
* Don't prettify JSON in the plugin library
* Indicate in plugin library whether a plugin requires reloading
* Display the highlighted plugin name in the plugin chooser
And if there's no name field fall back to the part of the title after the final slash.
