Playground v0.2

## Goal is to focus on the educational aspect of the Playground
The current playground works fine, the basics are there. However, we need to improve the usability. When the playground is shown to users, they don't know what to do, there is too much complexity.

New users, defined as those opening the playground for the first time, need to be walked through the process of composing a transaction. That includes creating their first account and their first notes. For that, we will return to a more graphical interface for composing a transaction.

## Rework the compose transaction tab and
We need a visual representation of a transaction. It should be a diamond shape in the middle. The left could be inputs, and the right could be outputs. The goal is to create the transaction and then prove it.


1. First, the user chooses an account. This is the only action the user can take on this page at that time, and we should graphically indicate that.
1.1. At first, no account should be preselected. The user can only click the button to add an account (indicated graphically somehow).
1.2. After clicking the `+`, the user is redirected to the Editor page that we already have. We need to walk the user through how to create an account. First, choose components, then if the user wants, create a custom component.
1.3. Once chosen, the user can inspect the complete account in the editor; only minimal info is shown here: Account name (= ID), major assets shown as symbols, then `...`, if storage is populated, show only the 2-3 major slots
2. Now, "Add transaction script" and “Add notes” are clickable (indicated graphically somehow). "Execute" is still greyed out 
(says “Either choose a note to consume or create a transaction script” when a user tries to click it)
3. The transaction script can be chosen after it is created in the editor. It should be indicated that the user can use the default transaction script.
5. Notes can be chosen after they were created in the editor; After clicking the `+`, the user is redirected to the editor.
5.1. It should be indicated that the user can use one of the default note types (P2ID, P2IDR). The playground should help the user to create the P2ID script by adding the created Account ID to the note inputs.
5.2. After a note is chosen by name on the Compose Transaction page, only minimal info of the note is shown here: Note name (= ID), major assets shown as symbols, then `...`, note inputs (first input).
5.3. If multiple notes are selected, they can be re-arranged, and the sequence can be defined by drag and drop.

## Minor feedback on the Editor page
- For an account, let's use only two files, the code/components files and the info file:
- The info file should have 4 sections: Info, Vault, Storage.
- Info should be a table with three rows: Name, ID (show prefix and suffix as tuple), Nonce.
- Vault can be shown as today
- Storage can be shown as table as well. The table has sub-sections depending on which component is chosen by the user. That means, the `authentication`-component has 3 rows, the `wallet`-component has 3 rows and the `custom`-component has 3 rows. They all start with slot `0`. The user can add new rows using a `+`. The authentication component should have the account's `pub_key` in slot `0`. The rest can be unpopulated at account creation.
- For a note, let's do the same. Show one info-file, in which there is Inputs, Metadata and Vault.
- The Inputs can be shown as table (up to 16 rows) which the user can edit.
- Vault should be similar to the account vault section (users can also add assets here)
- Metadata can be another table. Some data should be fixed, we can chose a random serial number for the user. But the Tag and the `Aux`-field can be populated by the user. The Metadata should also show the `recipient`, which is computed by `hash(hash(hash(serial_num, [0; 4]), script_root), input_commitment)`.

## Creating and choosing output notes
- Users can choose to output notes for their transaction. But they don't have to. Only when the output note is `public`, the user must define it.
- The process is similar to the ones with input notes.

El issue describe una revisión importante de la UI/UX para el flujo de composición de transacciones del playground. Comience explorando el código de la UI existente del playground, probablemente en los componentes del frontend. Busque la pestaña o la página del editor para componer transacciones. El objetivo es implementar un constructor de transacciones visual con forma de diamante, con pasos guiados para la creación de cuentas, selección de notas y adición de scripts. 'Hecho' significa que un nuevo usuario puede ser guiado a través de la creación de su primera transacción con indicaciones gráficas claras.

Escrito por el modelo de indexación a partir del texto del issue.