"shown" and "hidden" events triggered. Scroller refreshed on "shown".

The "shown" and "hidden" events are triggered after the "show" or
"hide" functions have been invoked. Container views propagate the
events down to their children to ensure they receive it.

This behavior gives a hook to views to update their layout when
the view moves from a hidden state to a displayed state. Typically,
this is needed for views that embed iScroll to provide a custom
scroller. iScroll listens to various events and refreshes the
dimensions of the scroller accrodingly. When these events occur
while the view is hidden, the scroller simply disappears. On top
of this, the dimensions of the viewport might have changed when a
view is displayed again (e.g. following an orientation change),
so the scroller needs to be refreshed in any case.

The phone UIElement adapter takes care of all this. Containers must
either derivate from UILayout or ensures that they propagate
"shown" and "hidden" events to their children.
UIElement phone adapter: removed remaining call to console.log
ListItem: fixed setElement that did not call the child's function
New FadeInPanel view that uses a fade-in effect between cards.
ImageLoader: added possibility to specify a selector for img container

Also added top comments that explain how the view works and how
to write compatible markup and CSS for a loader and fade-in effect.
New ImagesLoader view for multiple images. New "load" event triggered.

The ImagesLoader view is similar to the ImageLoader view except it
takes an array of images as input. The images extractor may be
specified in the getImages parameter. See inline comments for details.
By default, the view extracts all <img> tags.

Each image may be updated before the "loading" class gets applied if
the processImageEl function is passed as parameter. This function is
typically useful to add a spinner while the image is loaded in the
background.

The commit also includes the foundations for a "load" event triggered
by all views whenever the view is done loading its assets. The event
is triggered at the end of the "enhance" function by default but that
behavior may be overridden in derivated classes by setting the
"customLoadEvent" flag. Containers typically trigger the "load" event
when all of its children views have triggered their. Images loader
views only trigger the "load" event when images are done loading.

This event can be used to display a spinner up in the hierarchy of
the application, e.g. in the title bar or as an overlay in the
middle of the screen. The "load" event must be fire once and only
once each time a view is rendered.

Note from the author: the "load" event has not been thoroughly tested
yet. I am about to use it in the Sleek template for the pictures
listing view.
Layout view: fixed incorrect template parameter
Loading class automatically handled by views when requested.

The "loadingClass" view initialization option may now be passed
around to all views to tell the view to add the class to the view's
element between the time when the beginning of the "enhance" function
and the "load" event, in other words while the contents of the view
are loaded by the browser.

This is typically only useful when images are loaded in the background.

The "dataLoadingClass" initialization option may also be passed to
list views to tell the view to add the corresponding class to the
view's element while data is sync-ed. It is "loading" by default.

The data loading classname and the view loading classname should be
different to avoid conflicts (when data is sync-ed, the class would
be removed from the view's element, but render might have been called
in the meantime, meaning the view loading classname might have been
added).
Merge branch 'backbone' into backbone-fdj

Conflicts:
	lib/ui/listitem.js
	lib/view.js