Spanish translation. Thanks johnfelipe.
remove old homepage content and styles
new homepage copy and basic layout
add images to marketing homepage
remove unused images from old homepage
add helpful links to nav bar
First go at scraping Labour speeches.
Cope with different container in older Labour speeches.
Labour speech scraper - name corrections.

Some manual name corrections, and some things which are obviously
not names to skip for now.
Add images to the labour speakers.

For now this is just hot-linked. We should perhaps consider storing
our own copy of the images, or better still hosting a PopIt of
politicians and using that.
Some missing translations.

And update .po files.
Translate missing form field/button.
Use a slugify function that copes with Mandarin names

At the moment, if you create a speaker or section with an entirely CJK
name (as @clkao has done in an example instance for Taiwan) this is
slugified to the empty string, which then breaks any view that tries to
reverse() to get the URL.

The slugify function that is used is picked by the
mysociety-django-sluggable package.  This can use whatever slugify
function you specify with the SLUGGABLE_SLUGIFY_FUNCTION setting.

For sayit.mysociety.org we weren't specifying one of these so we were
relying on the default which is:

 - If unidecode is installed:

     lambda s: unidecode(s).replace(' ', '-')

   This copes with the Mandarin names (converting to Pinyin, as I
   understand it) but it doesn't downcase, collapse whitespace, etc.

 - Otherwise, if pytils is installed, slugify from pytils.translit is
   used.  This doesn't cope with CJK characters, however - it still
   slugifies our test case to the empty string.

 - Otherwise, it tries to use django.template.defaultfilters.slugify.
   This also fails with an all-CJK name.

So, this commit sets SLUGGABLE_SLUGIFY_FUNCTION to the slugify function
from the python-slugify package, which copes well with the cases I've
tried.  The other alternative is the awesome-slugify package, but that
doesn't downcase by default so I've gone for python-slugify instead.

The question that bothers me is whether this commit is in the right
package - it would probably be better to change
mysociety-django-sluggable's default to check for the existence of
python-slugify in preference to the other slugify functions, and then
change the setup.py of the sayit application to make sure that
python-slugify is installed. This would mean that the more useful
slugify function would be used by default for anyone using the sayit
application.  However, in the interests of getting a quick fix done, so
that @clkao can continue working on http://sayit.mysociety.org while the
core SayIt developers are away, this seems like a reasonable step.

Fixes https://github.com/mysociety/sayit/issues/360