Generalized Function run GUI and argument declarations

Mainly for Max: like with Sharable Editor, I think we can have a generalized Function execution GUI in Clotho and thereby avoid having to make custom GUIs for every Function. A Function declares its arguments and their type. Effectively, they define a Schema, and you have already successfully been able to contruct a GUI provided a Schema. So, having a GUI in which you declare the arguments for a 'run' is indistinguishable from the SharableEditor. The only difference is the output, which must be added and visually distinguished. The Schema of the output is also declared by the Function (though it is not currently captured in the Function SharableEditor). Thus, the appropriate visual presentation of the output can also be deduced by inspection of the Function.

When a user types 'revcomp' into the searchbar, it is first trying to confirm which tool they really meant, and that is the purpose of autocomplete. Once a user has picked a tool, ideally the searchbar is contextualizing the remaining suggestions or providing hints about how to express arguments. One challenge here is that conversion will also take place and thus the user might not really need to provide all the information asked for by the algorithm. In terms of how Functions are written, what I already see us doing, and what I think is actually the right solution, is for Functions to only take in as argument the information they actually care about to complete their task. For example, PCRPredict just needs three Strings, and perhaps indication of their strandedness. The simplest definition of a sequence object would be:

{
"sequence" : "atcgRNSDWu",
"isCircular" : true,
"isSingleStranded" : false
}

And that is all a PCRPredict algorithm really cares about, and thus it should declare that as the Schema for its three sequence arguments rather than a NucSeq, Polynucloetide, SBOL, etc. Note that this circularity and strandedness info is not captured in SBOL, so this is a distinct Schema. And it throws out much of the other info (annotations, notes, etc.) that are included in NucSeq and Polynucleotide.

So, philosophically, the Schemas chosen as arguments for a Function should try to reuse existing Schemas (for convenience and avoiding duplication of code) but the Schema should best capture the information required of the Function, and that is the principle concern. Converters can take care of the interoperativity.

If Functions are written this way, then the automatically-generated GUI should come out the way that will make sense to the user: they just need to supply the minimal information required as defined by these schemas.

Also in terms of searchbar function, when a user types in revcomp this could mean two things: they want to look at the code and metadata about it, or they want to run something on it. For all sharables, the link to the SharableEditor is already provided in all cases to access the first request. Hitting submit on it thus can cleanly imply the second. In the submit code, then, a failure to provide the proper arguments of a Function could logically result in opening a window providing the generalized run gui.