snowcap: add TextInput widget

[Ph4ntomas]

The title say it all.

This PR adds TextInput widget, which will be useful as a building block for e.g. prompts. On top of that, I've enabled support for key-repetition so the prompt themselves feel more natural.

TODO:

• [x] Basic TextInput integration
  • [x] Transmit text in Key Events (very basic for the time being)
  • [x] Enable key repetition
  • [x] on_input event
  • [x] on_submit event
• [x] Advanced TextInput integration
  • [x] Styling support
    • [x] Implements all & methods
    • [x] Make gradient less unwieldy (add strongly typed angles & better color-stop handling)
  • [x] Copy/Paste support -- This works. The clipboard itself is not set-up. Not sure if I'll set it up in this MR
  • [x] cursor control from the config ?
  • [x] Find a way to focus text input from the config
• [x] Rust configuration support
  • [x] basic
  • [x] advanced
• [x] Lua configuration support
  • [x] basic
  • [x] advanced
• [x] find & remove server-side except() and raw unwrap() ~Postponed to #370~ Removed the ones from this PR.
  • [x] add a TryFromApi trait so we can log error iso crashing.
• [x] Documentation
  • [x] Rust
  • [x] Lua

[Ph4ntomas]

• [ ] find & remove server-side except() and raw unwrap()
  • [ ] add a TryFromApi trait so we can log error iso crashing ?

@Ottatop do you have thought on that ?

Most except and unwrap are justified in the sense that the config library should always produce 'correct' value, but IMO the server should be resilient to protocol error.

The second point is only for types without a default implementation. If a default exist, I'd assume unwrap_or_default() to be called instead (tho we might tracing::warn! when that happen if a value was expected).

The alternative is to hardcode our own default when the translation between protobuf & iced types fails.

[Ottatop]

do you have thought on that ?

Agree, it would be best to crack down on these panics (especially if anyone wants to make protobuf bindings), though I strongly recommend doing this in another PR seeing as this one's already up to 2.5k lines

[Ph4ntomas]

though I strongly recommend doing this in another PR seeing as this one's already up to 2.5k lines

Agree, I'll only try to remove the ones introduced by this PR and removable :)

[Ph4ntomas]

Allright, I think that's all.

FYI, the PR is on top of #364. because I needed some of the changes from that PR, and it makes for a cleaner history that cherry-picking the commits I need (plus the eventual rebase hell if I discovered some issue in that PR).

It should rebase cleanly should you choose to first pull the other one, and then rebase + merge this one (which could also be easier to review, I guess ?)

OTOH, you can also close the other one and track everything here if you prefer.