Store lane configuration in database

[leonardr]

This branch replaces the old Lane class with a new Lane class that's an ORM object. The features of the old lanes are still available, with the following exceptions:

1. Individual lanes are no longer explicitly set as 'searchable'. All lanes are searchable so long as they are not limited to a genre or custom list. Lanes that are the root lane for one or more patron types are also searchable, no matter what. (This can cause problems if a lane based on a custom list is also the root lane for a patron type -- I don't think this will work, but I also don't think it wlil happen in real life.)
2. It's no longer possible to define a lane in terms of the languages not covered by that lane.
3. It is now possible to define a Lane as recursively including some Genres (i.e. those Genres and their subgenres) but recursively excluding other Genres. This currently has no real effect beyond what was possible before, because our genre structure only goes two levels deep.
4. The purpose of lane visibility has changed. Previously, invisible but searchable lanes were used to get the desired search behavior. Now, a lane is made visible or invisible to hide it from or show it to library patrons. The behavior has also changed: the children of an invisible lane are now always invisible themselves.
5. Previously, a constructor setting allowed a lane to inherit its parent's behavior when it was created. Now, this behavior is controlled by a database field, inherit_parent_restrictions. If this is set, a Work will only show up in a Lane if it would have also shown up in the parent lane. This works even when one or both Lanes are based on CustomList membership.

The LaneList class has been removed, as have the various subclasses of Lane. Both of these are replaced by the WorkList class, a generic implementation of "something that can obtain a bunch of Works on demand, and also might have children that are also WorkLists". The Lane class uses WorkList as a mixin.

Other notable changes:

1. The code that runs the core "find a bunch of Works" query no longer supports Work as its work_model. Now you have to use a materialized view. Although the Work feature was originally how this whole thing worked before we created materialized views, at this point it was only used in tests and it made the code significantly more complicated.
2. When choosing which books to feature for a grouped feed representation of a lane based on a CustomList, we privilege books that are featured on the CustomList over books that are of 'featurable' quality but not featured on that particular list. So a "bad" book might be featured over a "good" book if the librarian decides this is that kind of list.

This is the basis for a new feature branch, so I won't be merging it immediately after the PR is approved.

[aslagle]

we should update the date of this migration before merging.