Client build: modularize search input plugin from ui.js
Apply stable 782cf1a to next-stable
merge
Client build: modularize loading indicator from ui.js
Client build: modularize fa-icon button from ui.js
Client build: modularize popup menu from ui.js
Client build: remove ui.js; modularize icon button from ui.js
insert empty string instead of None for requirement.version
Client build: remove references to ui.js in client and templates; mv scripts/jq-plugins/ui to more generic/catch-all scripts/ui/
Lay the ground work for abstracting tool XML parsing out of galaxy.tools.Tool.

First part of a long process - this handles outlining a couple parsers and setting everything up to pass the parser into Tool.

Long term this should allow us to support (in core - if not the whole ecosystem) - multiple tooling formats (YAML, CWL, etc...). But it is also important from a purely design perspective - this core logic class should not be doing XML parsing.

As part of this I am building a test YAML tool description - but it cannot yet be loaded by Galaxy and should not be considered part of Galaxy's interface - it is there just to test two implementations are possible - obviously a broader design discussion would need to happen before we support a new YAML tool format going forward.
force_history_refresh does nothing so I am just setting it False in tool.

(TODO: Update planemo linter to mark this as a problem.)
REbase into initial commit.
Parse name, id, and version using tool source abstraction...

instead of XML directly.
Tools: Parse is_multi_byte from tool_source instead of from XML directly.
Tools: Parse display_interface from tool_source instead of XML directly.
Tools: Reduce code duplication in XmlToolSource.
Rebase into is_multi_byte commit.
Tools: Parse require_login from tool_source instead of from XML directly.
Tools: Refactor request parameter translation for new tool_source abstraction.

Interface itself relies on producing an XML element still - but it is optional - so we don't need to modify the interface until we want to allow data sources to be non-XML (less interesting than tools more generally I suppose).
Tools: Parse command and interpreter from tool_source instead of XML directly.