New attributes to Tool model to support tool-based interface

[prioux]

As we move towards an interface promoting the selection of Tools as the first step to launching tasks, we'll need to categorize the tools and display them in nicely named sets and subsets within the interface.

After talking to Ehsan, and seeing the prototype tool selection panel he created, it seems Tools can be presented in three groups:

• by software package (e.g. 'MINC', or 'FSL' or any other label to encompass software suites with many tools)
• by type (e.g. 'file conversion', 'fMRI', 'Diffusion' or other labels describing a general type of software)
• by arbitrary keywords (e.g. 'MIT', 'Oxford', 'Animal', 'Plant', 'TCP/IP', 'Crypto'... etc.)

To support all three groups, we'll add three attributes to the Tool model:

• application_package_name : a single string
• application_type : also a single string
• application_tags : a single string containing many keywords, separated by white spaces

The Tool model can be extended to include utility methods to get all these values in a cleaner format than just the standard attribute readers and writers. For instance, I suggest overriding:

• Tool#application_tags so that it properly splits on \W
• Tool#application_tags= so that it handles arrays or strings, and split by \W while reinserting a single space before writing back to the DB.

Note that this is issue is complementary to issue #72 such that once both are implemented, a CbrainTask programmer will be able to directly suggest values for all three attributes, which the admin can accept as is or change any way he/she wants when a Tool object is created or edited.

[eafkhami]

We're going to make the application_tags be delimited on commas "," rather than white spaces. This is because somebody may want to specify a tag with spaces in the tag