Merge remote-tracking branch 'origin/530-tree-change-the-hide-tree-button-by-a-more-intuitive-toggle-button-display-the-btn-in-the-lateral-bar' into dev

Merge remote-tracking branch 'origin/604-user-page-fix-the-error-message-when-the-page-loads' into dev

Merge remote-tracking branch 'origin/568-node-content-breadcrumb-display-the-full-path-of-a-node-as-a-breadcrumb-with-each-clickable-parent' into dev

For ngrams table, we set ngramsValidPatch = mempty because the table
is refreshed and we have issue
gargantext/purescript-gargantext#594

However, we need to keep that field, it turns out, because we have
gargantext/purescript-gargantext#598

Recently applied patches are needed for the document ngrams
highlighting.

This all would be unnecessary (or at least moved to the backend) if we
had
gargantext/purescript-gargantext#553

This reverts commit 058fa2fe.

The issue was this:

When user clicks around the ngrams table, only local state is
updated (`ngramsLocalPatch`). After he clicks 'Sychronize', this is
uploaded to server and `ngramsVersion` number is bumped up. What
happened is that `ngramsValidPatch` inside internal state was updated
and so the patch was sychronized locally, without refreshing the
table. However, this resulted in errors later, when user changed the
same term, because then, when user changes view to 'Stop terms', the
table is refreshed with the newly applied terms and `ngramsValidPatch`
doesn't make sense anymore.

The solution is to set `ngramsValidPatch` to `mempty` and, after state
is updated, refresh the current table.

It could be argued whether it's the most optimal thing to do and why
don't we keep things "offline". Well, clicking on 'Sychronize'
requires the client to be online so why not sync the table already at
this time?

I guess this makes things bit simpler and I think it renders
`ngramsValidPatch` unnecessary. So our state could be
simplified (patches is already a complex beast).