in order to valid recipient

Transactions DO NOT have a year. its only DD/MM. In some cases, if there
aren't enough
transactions in the account, a transaction dating from last year has its
date incorrectly
guessed (with the date_guesser/ to avoid this we had to reduce
data_guesser.date_max_bump
to 2 in order to prevent such problems, but only for savings accounts.It
is not perfect,
hence the assertion to make sure we aren't returning a future date that
is more than 2 days forward.

At date "2018/12/03", the site only shows one transaction with date
"29/12", so this interpreted as "2018/12/29" (future) instead of
"2017/12/29" (past).
If there were more transactions in the year, this wouldn't happen

It is cleaner to check if transaciton type is SUMMARY instead of
checking if "CARTE" in raw label.

Boursorama loves to change the xpaths every 2 weeks so we need to adapt.
Now there are several <h3> on top of each <table> so we need to fetch
the first <h3> and check its text().
And the liquidities can be contained in two different tags: h3/h4 or
div/span.

Closes: 8782@zendesk

All immediate card transactions were filtered out from their parent
account because of issues in transaction typing as well as deferred card
transaction filtering.
For each account, ALL card transactions appear so we must carefully sort
transactions from deferred/immediate cards and only yield the immediate
ones since deferred card transactions are yielded separately (in the
history of the card).
This code enables correct detection of deferred card transactions
(mainly by checking if the account_label of the transaction appears in
the list of deferred cards).

Note: I also re-organized the order of iter_history() methods in browser.py
because it was a huge mess.

Closes: 8912@zendesk, 8308@zendesk, 8814@zendesk, 8773@zendesk,
8910@zendesk

This patch enables the filtering of coming summaries before they are
fixed otherwise they are inserted several times by the backend with
different amounts at every synchro.

Closes: 8853@zendesk

When several companies are present, you need to return to the main
company each time you finish to scrap the cards from a company (thx to credit mutuel
website). Moreover in the connexion used, more than 100 cards are
present and consequently some cards shares the same visible numbers. We
needed to had a second list to avoid some bad card replacement.

Closes: 8772@zendesk

    - original_currency detection was made throught label analysis, but it wasn't check the account currency
    - change args passed through iter_history to account from some specific account data to get more needed
    information (like currency)

On SG website, there is unavalaible message 'Le service est momentanément indisponible.'
when on the json page there is 'err_tech' error
raise BrowserUnavailable in this case (it's a tempory error)

raise BrowserUnavailable when there is error message
'Le service est momentanément indisponible' in this page

Closes: sibi@17476 zendesk@8736 zendesk@8597

Closes: sibi@31966 sibi@32542 zendesk@8697 zendesk@8729

No declarative code is used

Sometimes when one invest is splitted underneath in several sub
investments we now retrieve the data correctly.

The month and the day were inverted.

With the async method, (thanks to creditmutuel website) the navigation were sometimes random to reach the good page
in order to get the card type information. Consequently some immediate cards were
still returned. Here we replace with the open method (will do step by step to reach the good page).

Closes: 8831@zendesk