[FIX] models: display_name and name_get mismatch

- display_name useses of name_get and not the other way around:
The name_get should not call _compute_display_name, _compute_display_name should call namge_get. The previous behaviour was not backward-compatible with the old api. All the models redefining name_get (still

- Do not set an inverse function to display_name:
In most cases, writing on display_name writes on _rec_name (if any, not mandatory). If the display_name computation is redefined, we need to redefine as well the inverse method to avoid unexpected behaviour
This required to also modify tests in base_import as readonly fields are avoided.

- Remove search method on display_name:
For the same reason as for the first point, it could be good that searching on display_name use name_search (and not the other way around). However doing this would be very unefficiant (need to do the search, without limit, extract the ids of the name_get result just to generate a subdomain ('id', 'in', [...]). As in most cases it would anyway mean to search on the _rec_name it's better to directly do so.

- Changing label to avoid mismatch:
In view displaying the list of fields or when a match is made on the label of a field (e.g. when importing csv file, matching is made on both label and technical name), the fact that display_name field has '
Calling it 'Display Name' will avoid most errors.

- remove display_name definition from website_forum_doc,ir_model:
These fields are doing the same thing as the display_name of the new api, we can remove them. We need to keep the one for res.partner as it's a stored field.