Experimental UI form separation

[VakarisZ]

Description

This branch is a concept to solving the problem of component explosion.
SEE LAST COMMIT ONLY

The problem

The data that the back-end API's use are not consistent.

Example data that the back-end gives and expects:

{ 
  "firewall": "enabled",
  "allow_password_login": true,
  "user_count": 1,
  "device_cound": "3"
}

This means that in the UI we need at least 4 components to display the data. ("enabled"/"disabled", true/false, int, int as string).

Instead, there should be only 2 components int the UI: bool and int.

The proposed solution is to create a UI version of the form:

{ 
  "firewall":  true,
  "allow_password_login": true,
  "user_count": 1,
  "device_cound": 3
}

The idea is to clone the form data and link the back-end form data with the front-end form data.
To be more specific:

1. Each view should be able to include the optional translation layer
2. In the translation layer, devs should be able to link the form values together via "computed" properties (see the last commit in this PR).

Benefits

The main benefits of this change is code design. After this change the codebase should have a lot less components and instead have a collection of "computed" properties that can be used for translating UI component state to what the various API's expect.

It would also allow us to v-bind form properties to the components, further simplifying the components and separating component logic from domain logic

[VakarisZ]

This binding could be extracted into a composable, it doesn't need to be part of the form