Introduce the Line object concept and use the Grouping

Another huge piece of technical debt is the way
the 'lines' of the tables are handled

• Data storage is split between:
  • the duo of OrderedDict grouping_counts and grouping_groupings, populated in retrieve_data and passed through to process_data
  • the dictionary of OrderedDict column_data, stored as object attribute and used later in make_stats_for_one_grouping.

• The no_groups grouping, and to a lesser extent the totals and footer, even though they share conceptual similarities with other 'lines', are handled independantly.

• Crazy logic involving the ill-fated GROUP_MAPPING

• get_query_for_items_for_property_[nega|posi]tive are still a mess of if/then statements (even after the Column refactoring)

This is becoming more of a problem as we want to introduce more grouping types.
The Year grouping added in 0a8e7fb8 already stretched things a bit thin,
and we are looking into adding support for Lexemes.

Here we introduce the 'Line' object concept tree:
AbstractLine
└── Grouping
   ├── PropertyGrouping
   │   └── YearGrouping
   └── UnknownValueGrouping

A Line object has a count.
A Grouping object also potentially has a title and a higher_grouping.

get_grouping_information is modified to return a list of Grouping objects
instead of the duo of OrderedDict grouping_counts and grouping_groupings,

For now, we unpack the Grouping object when calling make_stats_for_one_grouping,
but in a future refactoring this will become a logig of the Grouping object.

Also alter several unit tests, including the ones added in e8f045af53.

Next step is to store the column_data data into the Grouping objects.