Newer versions of polib accept only unicode strings in the
`pofile` function (because they check if they start by the decoded
version of the BOM).
I changed the `data` that is passed to `pofile` to be a unicode
string in Python 2 too. This seems to work locally in my old
version of polib, so that at least the old behavior should be
kept the same.

- The warnings are compared in a set instead of a list, as we do
not care of how many times is the warning raised.
- The warning filter is added inside the context manager, as
recommended in
https://docs.python.org/2.7/library/warnings.html#testing-warnings .
- We change the `clear` method of list, using `del` instead, as the
`clear` method was added on Python 3.3.

Instead of using encode/decode is it better to use str2bytes and
bytes2str, so that the types in Python 2 are unchanged. More important,
this prevents the double encoding of bytes, which causes problems
when they have non-ASCII data encoded.

Errors were being raised for returning `None` in Python 2
(due to a missing else branch) and for re-encoding bytes
in Python 2.

I changed the code to use str2bytes in the cases where bytes
are expected.

with ROUND_DOWN, we have a different behaviour between py2/py3, that caused failures in
erp5_simplified_invoicing:testTradeModelLine.

Here is what happened in _round(1.9999999999999998) in
bt5/erp5_simulation/DocumentTemplateItem/portal_components/document.erp5.FloatEquivalenceTester.py

* py2
decimal.Decimal(str(1.9999999999999998)).quantize(decimal.Decimal('0.000001'), 'ROUND_DOWN')
=> Decimal('2.000000')
(because str(1.9999999999999998) is '2.0')

* py3
decimal.Decimal(str(1.9999999999999998)).quantize(decimal.Decimal('0.000001'), 'ROUND_DOWN')
=> Decimal('1.999999')
(because str(1.9999999999999998) is '1.9999999999999998')

But ROUND_DOWN result of 1.9999999999999998 with 0.000001 precision should be 1.999999 thus py2 behaviour is wrong.