#### Steps to reproduce
1. Create a fresh DB with the Brazilian localization.
2. Create a new Credit Note (directly from the menu, not from an invoice). Confirm.
3. Observe that you get a ValidationError: "Another entry with the same name already exists." because the name of the Credit Note is NFe 00000001, and an invoice called NFe 00000001 already exists.

#### Analysis
- The credit note should be called NFe 00000002, because in Brazil the same sequences should be used both for invoices and for credit notes of a given document type.
- However, because the `refund_sequence` field is set to True on the 'Customer Invoices' journal, the sequence mixin doesn't consider invoices and credit notes as using the same sequence, and therefore doesn't consider the existing invoice when finding a new name for the credit note.

#### Solution
- Set the field `refund_sequence` to False on the journal created by the l10n_br template.
- We also take the opportunity to move the code that provides a default name to the demo invoices to a separate file demo/account_demo.py, for consistency with other localizations.

The goal of this commit is to resolve:
=====================================
1. When you edit a Char or Boolean field with an onChange that returns
   the value before editing, you must display the value of the onChange.
2. In the model, html fields are always Markup fields. But when we evaluate
   a modifier containing an html field, we use the server value (a string or false).
3. When we edit a field and its onChange returns an server error, we want to
   revert its value to the valuea before edition.

Solution:
=========
1. Always render when applying a change, even if the value does not change,
   because onChange returns the initial value. To do this, we'll apply
   the changes to record.data, then apply the changes from onChange.
   The value will therefore change, which will cause all the components
   observing the value in record.data to render.
2. When we update an html field, its value will always be markup and
   we'll store it as a string in _textValue so that we can evaluate the
   modifiers without the markup. For changes coming from the onChange, we
   will store the value in _textValue and apply markup on it for record.data.
3. When an onChange returns an server error, we will apply the changes and then
   revert them directly. This will have the effect of triggering a rendering
   on all the components observing to the record.data corresponding to
   the changes and so displaying the values before editing.

How to reproduce:
=================
Case 1:
------
- Go to a form view containing a boolean field with an onChange
- Check the boolean field
- The onChange returns with the value false

Before this commit:
    The boolean field is always checked

After this commit:
    The boolean field is no longer checked

Case 2:
------
- Go to a form view containing an html field and an field "x" with
  invisible ="not html_field" and an onChange
- Edit the field "x"
- The onChange returns the value false for "html_field".

Before this commit:
    The field "x" is always displayed

After this commit
    The field "x" is no longer displayed

Case 3:
------
- Go to a form view containing a char field with an onChange
- Edit the field
- onChange returns a server error

Before this commit:
    The field is marked as invalid and contains the value after editing.

After this commit:
    The field contains the pre-edit value