Allow two views, one for container page and another for category pages

Let me push this to 6.x, because I believe that the proposal makes a lot of sense.

The point is: Category_views module needs separate selectors for a view shown on container page, and a view shown on category pages (along with appropriate database storage, and upgrade path). We most probably then want to drop the checkboxes "show on categories" and "show on container", and add a 'none' option to both the new selectors.

This is needed, because the current workflow with the same view for both categories and container won't work. When the view gets a category CID as an argument, and then the same view gets a container CNID as an argument, you can't do much useful with that view. It's bound to be broken in one case, or the other. With separate selectors, we'll be able to use two views, tailored for both these different cases - or set both to the same view, if needed for some reason.

Additionally, while we're going to change the category_views settings data, we might want to move these setting to a more fitting place in the $node object, to be in line with the rest of category package.

So, I implemented this enhancement. Changes in this patch:

- Two separate settings for views on container page, and on category pages (all the way through the workflow). Flags/checkboxes "show on container" and "show on categories" are now removed; the default '<none>' option in the two view selectors replaces them (and it's cleaner too).

- Update function included - any already existing (6.x) settings are kept.

- Since the settings got changed, it's a good time for a little cleanup: Location of category_views settings in node object were $node->setting, which deviates from the general practice in Category package, which is $node->module['setting']. So, now we have settings like $node->category_views['view_for_cats'], which is more consistent.

- I also updated descriptions in the category views fieldset on container-node form. Now that we have two view selectors, it looks foolish to repeat the message about possible creation of more adequate views, so I extracted that to a description on the fieldset itself. I also added recommendations on argument usage on the views, as that's generally always needed (unless you do something _really_ special), and is a possible source of confusion.

I tested everything I can think of, especially upgrade path (all combinations of settings), install/uninstall of category_views, all combinations of category_views settings (including a combination of two different views really working), and container creation/edits/deletion workflow including previews.

Thanks for this. Committed to HEAD.