Need to flip order of creating `BlogIndexRelatedLink` and `BlogIndexPage`, otherwise `BlogIndexRelatedLink` references `BlogIndexPage` before it's been created and you get:
```bash
ERRORS:
blog.BlogIndexRelatedLink.page: (fields.E300) Field defines a relation with model 'BlogIndexPage', which is either not installed, or is abstract.
```
Multiply inherited StructBlocks and StreamBlocks now correctly order
their sub-blocks, in reverse MRO order. `declared_blocks` was being
overridden with `base_blocks`, which was screwing with the order.
Additionally, the order of fields when inheriting from multiple parents
is not obvious at first, so a comment has been added to the test
explaining the expected behaviour.
Only known fields are passed in to the template, instead of allowing any
arbitary data. Additionally, fields in value now appear in the same
order that they are declared in
This fixes a `unittest.expectedFailure`, by rearranging the tests to
test the correct things.
FieldBlocks should not return anything from `get_searchable_content`. It
is up to subclasses to override it and return something relevant.
`ChoiceBlock` overrides it to return the display value of the chosen
item.
The asset compilation that occurs as part of `python setup.py sdist`
would find all the files to include first, then recompile all the
assets, before finally packaging them all up. This means that if a new
file was created as part of the asset compilation that was not there
when all the files were first searched for, that file would not be
included in the package.
Now, the asset compilation happens before the file system is searched
for assets to include, so all assets should always be included.
This exposes an inconsistency between the old `PageManager.(not_)sibling_of` method (which was
exclusive by default) and `PageQuerySet.(not_)sibling_of)` (which is inclusive). We therefore
standardise on the inclusive behaviour (in line with treebeard's own sibling methods), and note
this change of behaviour in the release notes.
