Switch favorites collections to be their own folder type

Whereas previously collections-of-favorites were just plain old `@type='regular'` folders, now they're `@type='favorite_collection'` thereby differentiating them from regular-old-tabs.  This allows using traditional layout alongside collections-of-favorites.

**Un-favoriting favorited-by-default collections doesn't persist across logins.  This seems to be a known issue that apparently predates this changeset.  This changeset doesn't fix this and rather it's a problem considered out-of-scope for this changeset.  Baby steps.**

# Features:

The favorites portlet now lists applicable collections, with an example such collection ("News") included in this changeset:

![favorites_portlet_showing_news_collection](https://f.cloud.github.com/assets/952283/2225187/cf41eeca-9a88-11e3-99ad-9a73b99db7d8.png)

The structure transform is enhanced to understand how to tee up a single fragment for rendering (fragment-in-focus-mode essentially) so that when a user clicks on the name of such a collection-of-favorites in the Favorites portlet, that collection is rendered:

![rendering_the_news_fav_collection](https://f.cloud.github.com/assets/952283/2233657/9798aed8-9b2c-11e3-8518-7ac67c5c9a99.png)

External IDs for fragments are supported, taking advantage of the same support as exists for `@type='regular'` folders.  So, in the above, the portal canonicalizes to a "pretty" URL addressing the fragment rather than using the under-the-hood `u17l1s4`-style identifier.

That is, because in the `...fragment-layout.xml`, there's an `externalId` of `news-fav-collection` declared:

     <folder ID="s4" dlm:deleteAllowed="true" dlm:editAllowed="true" hidden="false" immutable="false" name="News" type="favorite_collection" unremovable="false">
      <structure-attribute>
        <name>externalId</name>
        <value>news-fav-collection</value>
      </structure-attribute>
      ...

the URL canonicalizes to

`http://localhost:8080/uPortal/f/news-fav-collection/render.uP` rather than sticking with `http://localhost:8080/uPortal/f/u32l1s4/render.uP`.

The portal retains navigational state whilst users interact with portlets on the focused-upon fragment, so users can e.g. nudge a portlet into edit mode with no trouble:

![rendering_focused_fragment_portlet_interaction](https://f.cloud.github.com/assets/952283/2233673/eec80924-9b2c-11e3-97bf-a6839cb02dc5.png)


Existing theme support for rendering tab navigation is re-used (abused?) for rendering focused-upon collection.  The logo is enhanced to be a clickable hyperlink that returns the user "home" in the portal, providing a way to escape the focused-upon fragment.



# Implementation / design:

The implementation invents a new supported folder type `favorite_collection`.

The structure transform previously knew how to render a single portlet in focus mode or the dashboard view with one of the tabs selected, with the identity of the selected tab communicated via the folder-name portion of the uPortal URL ( `/uPortal/f/folder-name/...`).  This customization adds a third broad path in the structure transform, that of rendering one fragment "focused".  The structure transform detects whether the `focusedTabID` stylesheet parameter identifies a `@type="regular"` folder or a folder with a different type.  When the type is `regular`, handling is unchanged.  When the type is not regular, then the structure transform generates output XML representing that one folder as the sole `@type="regular"` tab.  (That the structure transform can re-write the focused-upon fragment's `@type` to be `regular` so as to take advantage of existing theme transform support for rendering regular tabs is an essential insight -- it makes this bit of progress feasible without a bunch of work to teach the theme transform new rendering tricks.  The theme transform will subsequently need some work to make this "look good", but this solution gets to "working".)

A new attribute on the `<navigation>` element coming out of the structure transform is invented, `@allowAddTab`, with the traditional dashboard rendering enhanced to mark this attribute `true` and the new one-fragment-focused handling setting it to `false`.  The `respondr` theme transform is enhanced to suppress the add tab UI control even if the user would otherwise have permission, when this attribute is not set to `true`.

Some incidental logging enhancements where better logging helped with troubleshooting development.

While this solution is developed for the purpose of the Favorites portlet being able to present useful links to favorited collections, the solution is more general in that you can now focus upon any (in-the-layout, not @hidden) fragment.  At the least, this is useful for troubleshooting other non-regular-type fragments, i.e., regions.

![rendering_the_header_right_folder](https://f.cloud.github.com/assets/952283/2234018/ec9cabbe-9b31-11e3-8ba7-1a74aaf0c5f8.png)


# Known shortcomings, deferred work, and technical debt:

* **Un-favoriting favorited-by-default collections does not persist across user logins.** This issue predates this changeset and this changeset doesn't fix it.
* **Does not detect** and handle appropriately the case where one attempts to focus upon a fragment **identifier that does not identify a fragment**, or that identifies a fragment that is not in the user's layout.  At best, fails silently. However, the status quo before this changeset is to fail silently when attempting to address a layout node that cannot be found, so this is not a differential shortcoming of this changeset. :)
* At least as the admin user, one can un-favorite a collection-of-favorites but that **un-favoriting does not persist across logins**.  This might be an admin user edge case.  I don't think this pull introduces this defect so much as it just doesn't do anything to address it.
* The favorites portlet **`view.jsp` uses knowledge of portal URL implementation details** to compose the URL users follow when they click the name of a collection-of-favorites, but it should probably be using an API instead and not have that URL composition implementation detail coded into the JSP.  However, this changeset doesn't touch that JSP, it just fails to improve this.
* The **structure transform signals too little to the theme** about the nature of the invented tab representing the focused-upon fragment in the navigation, whereas that should probably be better flagged so that the theme can better style it.  This will be presumably be addressed in a subsequent UI enhancement pass since (also known shortcoming) this just doesn't look like the mockup yet.  (e.g., http://navy8o.axshare.com/#p=academics__interim_ ).
* The enhancement to the **portal logo** to add the link to go to portal "home" **is at odds with the change in `master`** to make that a simple content portlet rather than a JSP portlet.  Also, while the portal logo is now a functioning link to "go home", **it is ugly** and needs better styling.
* Does not add **unit tests** to exercise the new functionality in the structure and theme transforms.  XSLTs amenable to unit testing?
* Someday there will be a **rendering pipeline that evolves away from XSLT** as the templating technology.  This is not that day.