Revise categories handling of projects

[msteghofer]

When introducing the API (#41), we wanted to revise, how "categories" of projects are handled in CSnake, as there were some inconsistencies. The problem of the way categories were handled in 2.4.4 was that the concept was thought differently at the beginning from how it is used now. Here you can see a list of changes done in d540891 to the API:

• There was a list of "categories" for every project. That made sense, if you wanted to filter them with wildcards, as it was done in earlier days. But nowadays only the first of those "categories" is shown in the GUI and is rather a name than a category. So now a project has 2 names, one that is passed as "_name" to the project constructor and is not visible in the GUI and a second name that is passed as first entry of the "_categories" list and is used in the project tree of the GUI. In the API the "GUI name" (that was given via "_categories" before) is now obsolete, the real project name is taken for the GUI, too.
• As the name "categories" was already occupied (see first point) by something that was no longer a category but a name, we had to invent a new name ("super category") for what now really was a category (appeared on a higher level in the project tree of the GUI). Those "super categories" are now "categories" in the API. Besides, they don't have to be set via a csnContext (!) member function, but can be passed to the project constructor as "categories".
• There was only one level of categories (super category -> categories) in the tree. The API allows now several levels. As the GUI doesn't allow this yet, internally those categories are merged together into one category ("Gimias" -> "Plugin" -> "CardioSegmentationPlugin" will become "Gimias / Plugin" -> "CardioSegmentationPlugin").

Now we have to clean up the core in a consistent way, meaning:

• Remove "features" (e.g. lists of names instead of one name) that cannot be used any longer because the API already prohibits them.
• Let the GUI put up with the promises the API makes (several levels of categories in the project tree).
• Refactor the functions in csnProject and csnContext to have a naming and structure that is consistent with the API.