Refactor: Update Signals readibility and ergonomics

[GuilhermeF03]

Is your feature request related to a problem? Please describe.
Right now, signals are updated and set directly by using the value field.

// Update
signal.value = 10
// Read in-place
log.info {"Current value is ${signal.value}"}

However, it can become a bit cumbersome to use value when doing any update, specially if it's a complicated calculation

signal.value = (someSignal.value / otherSignal.value) / someOtherSignal.value

flag = signal.value > 10 && signal.value < 100

Describe the solution you'd like
We can look on how frameworks like Angular does it:

• someSignal() - reads value
• someSignal.update{ it +5 } - updates value based on previous value, or with direct values

Ergonomics
With these updates, now updating things becomes harder. Once we did:

someSignal.value +=5

And now we do

someSignal.update {it + 5} // less ergonomic

For these reasons, we can take advantage of Kotlin operator overload and add overloading for the operators:

+=, -=, ++, --

So now, updating it becomes

someSignal++
someSignal--
someSignal += 5
someSignal -= 5

Note

Direct updates still need the usage of .update

[GuilhermeF03]

We would need to explicitly overload the operators on each pre-defined types, and for future types, new operator overloads would need to be implemented. This becomes unmaintainable long-term.

Fix: keep the .update{ /* ... */ } for complex updates(e.g. signal.update{ it.filter{...} }), but read and writes are kept through access to signal.value