An association can have a description. It probably makes sense to show
it on the page which lists those associations. For past members, it
could be e.g. "left to become xyz at jkl"; in general it can be
anything that's contextual for the association.
Jinja-wise, `(" \n " ~ ass.description).rstrip()` will reduce to an
empty string string if description is empty; otherwise it will be two
empty spaces (new line) and a two-space indented description, which
should fill out a list item nicely.
If there are associations (with a person) with a defined end, they
will be shown in a separate list. The list will be sorted in a reverse
order of end date (that is, most recent alumni at the top). The time
period of the association will be shown, with "since..." or "until..."
inserted if either start or end time are missing.
Note that, on either Start or End, `at_time` is not a required field;
an End which only defines `at_location`, or even one without any
properties (other than the schema class), would be valid. This
necessitates slightly clumsy checks on properties.
In the absence of a defined end, a person is assumed to be a current
member. This commit does not change that (filtering by `.ended` has
been done previously), it merely exposes the distinction by also
showing associations which ended. This means: a project page will be
only as good as the information in the pool.
There are possible edge cases, in which a person was associated with a
project more then once (e.g. with different roles over two time
periods). Because we are iterating over associations, not associated
persons, a person could be listed in two lists (current and past). I
am curerently not sure whether we should be grouping by person
instead, and if so, how to implement that, but it does not seem
critical.
