Fixed a bug in list.js when the collection has only one item
Changed the way children are added to a list

Before: the children were added after the last existing
children of the list. It didn't work when the list was
initially empty.

Now: the children are appended to the itemContainer. The
itemContainer is found by getItemContainer which tries to
find an appropriate container.
Merge branch 'master' into alu-mvp (NEEDS MORE FIXING)

Note the code "works" as before but actually needs fixing because the
load more feature makes invalid assumptions about the structure of the
DOM.

Conflicts:
	lib/ui/list.js
List view: code linted

No real change introduced at this step, I simply applied code
guidelines more consistently.
List view and base collection: "load more" improved and Woodman logs

The base collection wrapper now triggers "load:more" and "load:last"
events and maintain a "hasMore" flag initially set and reset when
the collection receives fewer items than the number of items requested
in a fetch request.

I re-wrote the description of the List view to detail the options
available and simplified the "load more" feature. The code may still
need to be updated for other scrollers as the "onScroll" event is
kind of bound to iScroll way of thinking.

The "load more" feature does not create any additional markup anymore,
but flags the root of the view with a "loading" class name (which may
be specified when the view is created). This should allow all or
next-to-all possible animations to happen within the view to warn the
user that data is being loaded.

First few logs added with Woodman to track things down.
Base collection and List view: trigger more consistent "load" events

The base collection class now triggers a series of "load" events when
it is fetched. In order:
- "load:start" when fetch starts
- "load:first" when first fetch completes, provided it returned at
least one item.
- "load:more" when a subsequent fetch completes, provided at least
one new item got added to the list
- "load:last" when fetch completes with no new items or with fewer
items than the requested number.
- "load" when fetch completes, regardless of whether new items got
added to the collection.
- "load:error" when an error occurred.

The chain of events is more consistent than it used to be. The
"syncstarted", "syncsuccess" and "syncerror" events are still
triggered but are deprecated. They are synonymous to "load:start",
"load" and "load:error".
DynamicContainer: Woodman logs added, switched to "listenTo"

The update does not introduce any functional change to the view but
brings a bit of logging to the class. I also switched from on/off
to listenTo/stopListening to ease the garbage collection of the view.
Updated Woodman to v0.1.8 to fix empty config initialization issues

Previous versions of Woodman cannot load if an empty configuration
is provided.
Merge branch 'master' into feature-loadmore
fetchMore: new function in Collection, fixed in TV Grid/Verticallist

The base collection class now exposes a "fetchMore" function that
triggers a new fetch with the appropriate skip/limit parameters.
That function is used by the List view to retrieve more items.
The function does not take any callback, the caller should listen to
the "load" events it is interested in.

Previous commits broke the TV versions of Grid and VerticalList that
expected List to expose "loadMore" in another way. This commit fixes
the problem but note scrolling may still break when these views are
used:
- user may not be able to scroll to the last added images in a grid
- active item may go berserk in a vertical list when new items are
added (pressing up or down again fixes the problem).

As far as I can tell, these bugs existed before I made changes to the
List view.