executors: support sequences of 2-tuples as parameters

Some services require sending the same key with several different
values, ie. the final urlencoded string looks like

  param=val1&param=val2&param=val3

The previous scheme of using dicts for parameters did not allow for
that. Fix it by supporting sequences of 2-tuples, so the above query
string would look like that when passed in the Request object:

  (('param', 'val1'), ('param', 'val2'), ('param', 'val3'))

While adding that, change the serialize_flatten function to return
2-tuples and serialize arrays without specifying indices. Turns out
that some services expect an array to be encoded as:

  array[]=val1&array[]=val2&array[]=val3

instead of:

  array[0]=val1&array[1]=val2&array[2]=val3

With the new support for 2-tuple sequences, we can oblige such
services.
executors/urllib: fix parameter order in debug message
http: fix typo in docstring
desk: fix typo in docstring
mailchimp: fix parameters for the ping method
mailchimp: add some basic tests
auth: provide our own version of an OAuth filter

All external libraries have some issues, either not supporting
multiple parameters with the same name, wrong behaviour with unicode
or others.

A simplified version of an OAuth filter turns out to be
straightforward to maintain and keeps us from adding a dependency.
uservoice: use our own OAuth 1.0a implementation

This allows us to get rid of the hideous pre-urlencoding hack for PUT
requests.
uservoice: add support for support queues
zendesk: fix test failures under Python 3
setup: return a 1 exit code to the OS if python setup.py test fails
spreadsheets: improve syntax in a test
spreadsheets: skip tests involving namespaces on libxml2 >= 2.8.0

With lxml compiled against these libxml2 versions, the tests
fail. Should be investigated more in depth, but for now skip them.
xml: accept both <nil /> and <nil></nil> when serializing empty tags