function signatures (#236)

[redman-a]

This is perhaps a good point to share my progress. I have created fuctionSignatures.json inline with issue #236. Currently all documented functions have been included with "description" and "inputs" arguments supplied. There are a few point/issues to discuss:

• I have written the JSON in a form I find easiest to read and navigate (this is quite expanded), do we want it formatted to be more consistent with the MATLAB documentation?
• Do we want to include the "outputs" argument, from a brief play this doesn't seem to do anything?
• There is an issue with how MATLAB deals with

  "type": [
    "char",
    "choices={}"
  ],

  Unless an initial ' is supplied the suggestions MATLAB provides and autocompletes with tab are string scalars rather then character vectors. While I don't think this will produce any errors, as the use cases for such arguments are mainly in switch/case blocks and MATLAB returns true for "abc" == 'abc'. It may encourage users to use the string type more widely in EasySpin and there are many functions which cannot handle strings. Even though it is incredibly useful, should the "choices={}" argument be removed for all cases with character types?

• sop has an elastic number of input arguments, I'm not sure how best to account for this?
• Do we want to include undocumented/private functions and/or undocumented function methods?

Before this is ready to merge it is likely that several "name", "purpose" and "description" arguments will change to enhance consistency and simplify.

[stestoll]

Thanks for working on this tedious but important issue!

• JSON formatting looks good.
• Skip specifying outputs if that information is not being used by Matlab at the moment.
• If the handling of "choices={}" is a bug, please report to MathWorks. If it's needed to completely capture EasySpin's inputs, please try to make it work one way or another.
• It is unavoidable that strings are going to become more prominent going forward. I wouldn't worry too much about full support at the moment, just use them where appropriate. I haven't seen any user errors yet from this string-vs-chararray issue. The goal for EasySpin eventually should be to handle both input types gracefully everywhere, but it's not a priority at the moment. We can fix any related bugs as they are encountered.
• Regarding the variable number of inputs for sop, I don't have an answer.
• Don't include undocumented call syntaxes, undocumented functions and private functions.

[redman-a]

All previously reported issues have been addressed. (NB: the current autocomplete behaviour is as MathWorks intends).

The .json has been updated up to commit ed7601a

[stestoll]

This looks good. Thank a lot for this contribution!