This commit introduces significant improvements to the User Interface (UI) and User Experience (UX) of the Sign application. The main focus is on making the Sign Template editing process more dynamic by:
- Introducing role assignments in the PDF view sidebar.
- Removing the top bar of the Sign Template Edition.
- Making the Signer Roles more customizable.

Below is a categorized summary of changes:

### Template List View:
- Reorganized fields in the template list view for better clarity.
- Updated template sharing options; sharing link behavior now follows conditions.
- Added a cog menu for template editing actions.
- Moved settings from the top bar to the new cog menu.
- Removed the top bar from the template edition interface.

### Documents List View:
- Reorganized the documents list view; removed the grouping sidebar.
- Fixed redirection issue in the template form when selecting "Cancel" in kanban view items.

### Templates Edition:
- Added OWL Sidebar to render sign items dynamically.
- Displayed a notification suggesting "Create Template" if a document is used at least three times.
- Moved inline document name editing to the sidebar.
- Transferred "Access Rights" option from the top bar to the cog menu.
- Relocated "Save as Template" option from the top bar to the cog menu.
- Enabled partner selection in the sidebar when signing an uploaded document.
- Enabled role selection in the sidebar for template and document editing.
- Allowed dynamic addition and removal of signers in the sidebar.
- Added fold/unfold functionality for signers in the sidebar.
- Made placeholders for sign items available without debug mode.
- Added field icons in the sign items.
- Removed employee names from sign items.
- Updated the selection field to a dropdown menu when signing.
- Introduced the new "Strikethrough" sign item.
- Added auto-rendering of sign Signatures during template edition.
- Improved selection field edition by adding multiple options then pressing Enter.
- Made the dragging of sign items more smooth, fixing the coordinates.

## Discussion about Sign Item Roles new usage (storage-wise):

After this PR, we made it easier to customer Sign Item Roles with the new sidebar. It was requested, in the task specification:
1. The removal of the Many2One fields for the signers in the sidebar;
2. The addition of a input field instead for editing the name of the signer;
3. A hamburguer menu with the options of editing the signer variables.

For achieving this, we had to create a new Sign Item Role record at each signer addition, for keeping the modifications and making the signer specifically linked to the currently template being edited. This way, a same Sign Item Role record can be edited without any problems on the current template it is linked without affecting other templates.

We estimated the amount of storage in PostgreSQL that will be necessary handling millions of Sign Item Role records below. Starting by the estimated size of a row of this respective class in the DB:

| Column            | Data Type   | Size (Bytes)          |
|------------------|------------|----------------------|
| `id`            | `bigint`    | 8                  |
| `sequence`      | `integer`   | 4                  |
| `create_uid`    | `integer`   | 4                  |
| `write_uid`     | `integer`   | 4                  |
| `auth_method`   | `text`      | 24 (20 chars + 4 overhead) |
| `name`          | `jsonb`     | 50 (average)       |
| `default`       | `boolean`   | 1                  |
| `change_authorized` | `boolean` | 1                  |
| `create_date`   | `timestamp` | 8                  |
| `write_date`    | `timestamp` | 8                  |
| **Total (without overhead)** |  | **112 bytes** |

Row Size Calculation: Total without padding = 112 bytes, Row overhead = 24 bytes, Aligned total (8-byte boundary) = 136 bytes. This way, following the calculated byte per row, including overheads, we got:

| Number of Rows | Total Size (Bytes) | Approximate Size (MB) |
|--------------|------------------|-------------------|
| 500,000      | 68,000,000       | ≈ 65 MB          |
| 1,000,000    | 136,000,000      | ≈ 130 MB         |
| 2,000,000    | 272,000,000      | ≈ 259 MB         |
| 4,000,000    | 544,000,000      | ≈ 519 MB         |

Thus, we can conclude that the current approach is not too heavy on a super large use case. If we made a similar behavior using computed fields (i.e. creating the record only when any of the fields is customized), we would have to change the entire behavior of the signers interaction in the sidebar and we would still need to create the record anyway.

Co-authored-by: Ahmad <alah@odoo.com>

task-4387560