Marketplace BROWSE permission

Invents a `UP_PORTLET_SUBSCRIBE.BROWSE` permission and requires it for access to Marketplace entries.

Features
------------

Marketplace now predicates display of Marketplace entry listings and the category selector on the user having BROWSE permission on the corresponding portlet.

Example `permission-set.xml` data provides `Everyone` sees some entries, `Authenticated Users` see more entries:

![some_marketplace_entries](https://cloud.githubusercontent.com/assets/952283/2769385/9cc35cb6-ca50-11e3-9966-050abf6f532a.png)

and `Portal Developers` see all entries, since they might find them all technically interesting.

![all_marketplace_entries](https://cloud.githubusercontent.com/assets/952283/2769387/a3d1c4c0-ca50-11e3-8fc6-f672ace71398.png)

Portal Administrators of course have permission to see any entry they want since they have the `ALL_PERMISSIONS` meta-permission.

Whereas before this changeset one could write any portlet `fname` into the URL to view its Marketplace entry, now `BROWSE` permission is required to view the entry.


Implementation Notes
------------------------------

Tucked `BROWSE` under `UP_PORTLET_SUBSCRIBE` owner since it felt like it's more about end-user subscription than about portlet publication, but there's a strong argument to be made that this is about portlet publications more than it's about user subscriptions into layouts and so should be under `UP_PORTLET_PUBLISH`.

Known Shortcomings and Technical Debt
-----------------------------------------------------

* No special UI handling for zero visible Marketplace entries case.
* While illicit attempts to view marketplace entries are now blocked, they are not logged and no user-facing error messaging is presented.
* While Marketplace service considerations are factored out into a `Service`, no caching is implemented.  In practice I bet it's going to become necessary to add caching to the Marketplace-specific layer of data on top of `IPortletDefinition`s, which are cached in their registry which this code uses.
* Categories are not filtered by `BROWSE` permission in the marketplace entry, which means that a user could navigate to try to filter by a category they don't actually have permission to browse and so won't appear in the category selector.  This turns out to be a minor UI glitch but it breaks the conceptual feature of being able to model Categories for administrative purposes without their appearing in the UI for end user filtering by nuancing the `BROWSE` permission on those categories.  This is backlogged at Wisc for attention when improving the permissions syntactic sugar.  Speaking of which:
* Syntactic sugar is not yet added for declaring who ought to be able to `BROWSE` a portlet in the `portlet-definition.xml` file ala how the `SUBSCRIBE` permission is granted.  Rather, you currently have to use a `permission-set.xml` to grant `BROWSE` and that doesn't seem to support granting by `fname`.
* Additional responsibilities that could be moved to the new Service layer out of the Controller are not yet moved.