Manage sharing of MeetingItems among different members/groups

Done. Now: - you propose an item as member of a given (meeting)group; - you may select one or more groups that are associated to the creation of this item (but it does not mean that users from associated groups may see the item, etc; it is just a declaration)

But there is now a potential duplicate concept (it is solved, read further!): the "proposing group" and the "category". Indeed, in some cases the categories *are* the proposing groups (like for EGW). So in a meeting config there is a new configuration option (a boolean); useGroupsAsCategories. If True, the "categories" field does not appear anymore when creating or viewing an item. The "getCategory" accessor was rewritten and returns the proposing group if useGroupsAsCategories is True (and the category title if False). By default, useGroupsAsCategories is False.

The meetingitems_list.pt macro has evolved, too. Indeed, for EGW we like to display, for each item proposed in a meeting, columns with acronyms of the proposed group and associated groups. In other settings, other columns way be shown instead. So I've added a multiselection field in MeetingConfig?, "itemsListVisibleColumns", that allows one to select which columns will be visible in the meetingitems_list.pt macro.

Last but not least: now a user MUST be in a group in order to propose an item. It means that the basic Manager can't create items anymore (nor may he update it). So I've updated content.py (profile creation) to be able to create test users when a profile is created. For the default PloneMeeting profile, some users are created: pmManager, pmCreator1, pmReviewer1, pmCreator2 and pmReviewer2 (every time the password is 'meeting'). pmManager, pmCreator1 and pmReviewer1 are in group "developers", others are in the group "vendors". Now for testing PloneMeeting those users are directly available (I will need to update INSTALL.txt to explain this). The test system has been updated accordingly (before that, it created users).