[IMP] reference/user_interface: reformat and clarify views reference

In particular, the following changes are made:
- Use the `class` and `attribute` admonitions along with custom
  attributes to define classes, views' root attributes, views'
  components, and attribute values. This allows re-using the responsive
  design that was made for reference lists, and getting rid of the
  previous implementation that relied on class attributes, which were not
  intended for this usage and reduce readability while hindering further
  contributions due to a lack of flexibility (no admonitions,
  sub-attributes...)
- Use definition lists to define view types to allow for clearer and
  longer descriptions.
- Rewrite and restructure the explanations when there is a lack clarity.
- Extract duplicated content to included RST files.
- Display SVG images into dedicated admonitions.
- Fix RST and English mistakes.
- Rename `view_architecture` to `view_architectures`, as it lists all
  existing architectures and doesn't describe "the architecture of a
  view".
- Replace underscores with hyphens in image file names to improve SEO.

task-3458320

closes odoo/documentation#5237

Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>

content/developer/tutorials/backend.rst

@@ -56,13 +56,13 @@ Business objects
     Declared as Python classes, these resources are automatically persisted
     by Odoo based on their configuration
 
-:doc:`Object views <../reference/user_interface/view_architecture>`
+:doc:`Object views <../reference/user_interface/view_architectures>`
     Definition of business objects UI display
 
 :ref:`Data files <reference/data>`
     XML or CSV files declaring the model metadata :
 
-    * :doc:`views <../reference/user_interface/view_architecture>` or :ref:`reports
+    * :doc:`views <../reference/user_interface/view_architectures>` or :ref:`reports
       <reference/reports>`,
     * configuration data (modules parametrization, :ref:`security rules <reference/security>`),
     * demonstration data
@@ -1289,7 +1289,7 @@ A report is a combination two elements:
      the *report* contextual menu rather than the *action* one. There is no
      technical difference but putting elements in the right place helps users.
 
-* A standard :ref:`QWeb view <reference/view_architecture/qweb>` for the actual report:
+* A standard :ref:`QWeb view <reference/view_architectures/qweb>` for the actual report:
 
   .. code-block:: xml
 

content/developer/tutorials/getting_started/01_architecture.rst

@@ -64,13 +64,13 @@ An Odoo module **can** contain a number of elements:
     these classes are automatically mapped to database columns thanks to the
     :abbr:`ORM (Object-Relational Mapping)` layer.
 
-:doc:`Object views <../../reference/user_interface/view_architecture>`
+:doc:`Object views <../../reference/user_interface/view_architectures>`
     Define UI display
 
 :ref:`Data files <reference/data>`
     XML or CSV files declaring the model data:
 
-    * :doc:`views <../../reference/user_interface/view_architecture>` or
+    * :doc:`views <../../reference/user_interface/view_architectures>` or
       :ref:`reports <reference/reports>`,
     * configuration data (modules parametrization, :ref:`security rules <reference/security>`),
     * demonstration data

content/developer/tutorials/getting_started/07_basicviews.rst

@@ -23,7 +23,7 @@ List
 ====
 
 **Reference**: the documentation related to this topic can be found in
-:ref:`reference/view_architecture/list`.
+:ref:`reference/view_architectures/list`.
 
 .. note::
 
@@ -72,7 +72,7 @@ Form
 ====
 
 **Reference**: the documentation related to this topic can be found in
-:ref:`reference/view_architecture/form`.
+:ref:`reference/view_architectures/form`.
 
 .. note::
 
@@ -134,7 +134,7 @@ Search
 ======
 
 **Reference**: the documentation related to this topic can be found in
-:ref:`reference/view_architecture/search`.
+:ref:`reference/view_architectures/search`.
 
 .. note::
 
@@ -155,7 +155,7 @@ Search
 Search views are slightly different from the list and form views since they don't display
 *content*. Although they apply to a specific model, they are used to filter
 other views' content (generally aggregated views such as
-:ref:`reference/view_architecture/list`). Beyond the difference in use case, they are
+:ref:`reference/view_architectures/list`). Beyond the difference in use case, they are
 defined the same way.
 
 Their root element is ``<search>``. The most basic version of this view simply

content/developer/tutorials/getting_started/12_sprinkles.rst

@@ -17,7 +17,7 @@ read the reference documentation for a more complete overview.
 
 **Reference**: the documentation related to this chapter can be found in
 :doc:`../../reference/user_interface/view_records` and
-:doc:`../../reference/user_interface/view_architecture`.
+:doc:`../../reference/user_interface/view_architectures`.
 
 Inline Views
 ============
@@ -272,7 +272,7 @@ behavior customizations, we can add the ``options`` attribute to several field w
 In :ref:`tutorials/getting_started/06_firstui`, we saw that reserved fields were used for
 specific behaviors. For example, the ``active`` field is used to automatically filter out
 inactive records. We added the ``state`` as a reserved field as well. It's now time to use it!
-A ``state`` field is used in combination with a ``invisible`` attribute in the view to display
+A ``state`` field can be used in combination with an ``invisible`` attribute in the view to display
 buttons conditionally.
 
 .. exercise:: Add conditional display of buttons.
@@ -283,17 +283,17 @@ buttons conditionally.
     Tip: do not hesitate to search for ``invisible=`` in the Odoo XML files for some examples.
 
 More generally, it is possible to make a field ``invisible``, ``readonly`` or ``required`` based
-on the value of other fields. Note that ``invisible`` can also be appliedto other elements of
+on the value of other fields. Note that ``invisible`` can also be applied to other elements of
 the view such as ``button`` or ``group``.
 
-``invisible``, ``readonly`` or ``required`` can have ``True``, ``False`` or a domain as value.
-The domain gives the condition in which the property applies. For example:
+`invisible`, `readonly` and `required` can have any Python expression as value. The expression
+gives the condition in which the property applies. For example:
 
 .. code-block:: xml
 
     <form>
         <field name="description" invisible="not is_partner"/>
-        <field name="is_partner" invisible="1"/>
+        <field name="is_partner" invisible="True"/>
     </form>
 
 This means that the ``description`` field is invisible when ``is_partner`` is ``False``. It is
@@ -386,7 +386,7 @@ Search
 ------
 
 **Reference**: the documentation related to this section can be found in
-:ref:`reference/view_architecture/search` and :ref:`reference/view_architecture/search/defaults`.
+:ref:`reference/view_architectures/search` and :ref:`reference/view_architectures/search/defaults`.
 
 .. note::
 

content/developer/tutorials/getting_started/15_qwebintro.rst

@@ -25,7 +25,7 @@ Concrete Example: A Kanban View
 ===============================
 
 **Reference**: the documentation related to this topic can be found in
-:ref:`reference/view_architecture/kanban`.
+:ref:`reference/view_architectures/kanban`.
 
 .. note::
 
@@ -111,7 +111,8 @@ it is possible to add it outside of the ``<templates>`` element.
     Refer to the **Goal** of the section for a visual example.
 
 Let's give the final touch to our view: the properties must be grouped by type by default. You
-might want to have a look at the various options described in :ref:`reference/view_architecture/kanban`.
+might want to have a look at the various options described in
+:ref:`reference/view_architectures/kanban`.
 
 .. exercise:: Add default grouping.