[FIX] web_editor: get data-last-history-steps on corrupted data

Before this commit, the odooEditor was aware of the initial history id
by reading the data-last-history-steps attribute on the first node of
the editable. When there is a corrupted html in an html field, the
parsing made by wysiwyg can remove some node when it parses the string
value before it is read by the odooEditor. If that process remove the
first node, there is no way for the odooEditor to retrieve it.

This commit makes the wysiwyg responsible to retrieve the initial
history id by reading the string value rather than the generated dom
tree.

At the time of this commit, there is another problem in the editor
that make the above case easy to reproduce. Pasting a table containing
a tbody added a corrupted html. To reproduce:
- open note
- create task
- write a letter in the first paragraph
- hit enter (to create a new paragraph)
- paste into the last paragraph an external html containing a `tbody`
  tag.
=> the pasted html will not contain the table but will contain the
   <tbody> and therefore be considered corrupted.
- save the document
- click edit
- make any change in the document
- click save
=> traceback because the initial history id was not found when the
odooEditor was instanciated.

The reason it was not found is because the first node of the editable
was remove by the parsing of the jquery method `html` that removed the
first node.

This commit improve the retrievement of the id by reading the string
instead of the gerenated dom tree.

opw-3146216

closes odoo/odoo#111596

Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>