sv list file support, refactoring begins #2033

Separated out node logic from general logic in forms, defaults.  Still working on render.

Began supporting files.

Separation of logic includes using plugins for various areas of the sv list.  Began on the node_biblio plugin, since that is probably the most demanding.  Plugin system is cool.  Node plugins load on all LOP forms, but not on LOF.  But during render, only plugins for the current bundle are loaded.  Right now all the biblio plugin does is modify the form, but the same logic will be present during box render.
Fixed file urls #2033

Yes, there is file specific code in the generic sv list class.  But I wanted it to be able to default to using display_title when no other display function is provided.  That means I needed to implement display_title here.  Maybe the files class should override it instead?
Moved sv list classes into own files #2033
SV refactring continues.  People, biblio custom sorts.  #2033
Added book, event filters.  #2033
Added (and cleaned up) subsite plugin for sv list #2033
Assorted sv bug fixes #2033
SV - moved subsite forms into plugin #2033
sv list taxonomy plugin #2033
Added random sort to sv list.  #2033
Restored pager to sv list #2033

Not actually sure I'm happy with this one.  It's a core feature of the sv list, but it's scattered into several places.  Better as a plugin?
Added os_entity_view_mode hook #2033

This hook lets modules control which view modes are available to different bundles.  SV list will use it when offering view modes.

Implemented the hook for events, news, and profiles to add sidebar teaser.  os_files adds some placeholders to its view modes (although I don't think we'll be keeping them - I jsut needed something to work with for now).  os also implements os_entity_view_mode_alter, which adds teaser and full to all our bundles.
Removed code I didn't mean to commit #2033
SV list uses drupal display modes #2033

The display style does not adjsut based on what's available any more - it's stuck at teaser/sidebar/full.  This means you can select sidebar teaser for items that don't really have a sidebar teaser

Custom display styules will need to be reimplemented as view modes.

An update hook will be needed.  dipslay_body is now just body.

Do we want to worry about the order these modes appear in?
Fixed javascript for display styles #2033

This was so much easier to manage with a definitive list of view modes per bundle.  I sent that setting to Drupal.settings and let javascript work out what was available each time the content type changed.  So easy.

sort and more links do similar things, but I think it'd be nice to make them a bit more consistent.
Moved more link to new sv #2033

Resisted refactoring the form building.  It's more verbose than it needs to be, but it works so whatever.

Did a little fixing of the more link and pager rendering.
1. More link and pager wouldn't display at the same time.  The more link was expecting the number of nodes gotten to be greater than the max number of nodes.  But the pager automatically truncated them early, so this couldn't happen.
2. Multiple pagers on one page view weren't working.  Could have sworn we fixed this ages ago.  Stashed their ids and used those instead of using 0 over and over...
Started fixing sv list repeat events #2033

I cut down the three functions from the old box into one function, that's smaller than the smallest of the original three.  Basically I'm taking the array of event nodes and exploding it on the date field.  So if a single node has 5 dates, it'll be replaced with 5 instances of that node, each with different dates.

... but `entity_view` calls `entity_key_array_by_property` which reduces that group of arrays I made into a list of unique nids.  I think this is the first case I've found for a custom view function instead of entity_view.  Oh well.
SV list supports repeating events #2033

I was mostly able to keep this in the event plugin.  I added a render hook to the plugins.  It gives each plugin a chance to render entities.  Only if it returns no results does the default render run.

Using a custom render function, the events plugin skips past the entity_load and just does a node_view on each of the event nodes.  That's what we did in the old box.

I was able to keep the loop that split nodes with repeat rules into several copies of the same node (see prev commit).  I had to add a date_id key for each delta.  I also keyed the nodes by event timestamp, so they could sort easily after being split up.
Added content restrictions to sortby field #2033

Plugins can register 'sort' options with the new `sort_register()` function.  Originally I was planning on using any plugin's sort_* method as a sort, but then I have no label.  As long as I was adding a line to label each of them (which seems easy to forget) I figured just making it a function would be easier.

Just like with display styles, sort plugins send an array of type/bundle restrictions to Drupal.settings.  When the content type changes on the form, restricted elements (Event sort, year of publication, etc) are removed unless they're allowed.

These sorts exist for biblio and events.  I still have to add news and presentations.
SV list has biblio style sorting (pub year > created) #2033

There was already a query tag called biblio.  Needed a new one.