Refactor playground to not use toListFormField + Remove unused imports from examples

[PhilippMDoerner]

This takes care of the refactoring we had discussed for playground and for which I had written up a reminder in #106 : https://github.com/can-lehmann/owlkettle/discussions/106#discussioncomment-7350315

Does exactly what the heading states.

This PR should be mostly independent from the other 10. I distantly recall one of the other 10 requiring me to implement another toListFormField proc, but I can adjust that.

While I was at it I also noticed a couple examples importing modules they no longer need, so just cleared that up to remove those warning messages.

I also did a slight change to the Scale example, as it really does not look pretty when you add a mark with position top/right to it if it takes up the entire Window. So I put it in a Box() widget with expand: false.

[PhilippMDoerner]

Fixed all outstanding remarks.

Sidenote, 1 more addition I made was:

Apparently range is not covered by current toFormField procs. So I made one that works for all ranges. That required introducing a Range concept in playground though, because apparently proc x(r: range) is not a valid parameter typeclass to make a generic for all ranges. proc x[T: range](r: T) is not workable as that clashes with proc x(r: auto). I am confused and not happy I had to introduce concept, but at least the code works :shrug:

[PhilippMDoerner]

I had a eureka moment and this did suddenly inspire me to play around again with complete generic form generation for any type. I succeeded!

We can now fully generate the form for any given type with fields while still having the dummy-widget fallback for all those unknown types e.g. type Mine = distinct string. This brings with it basically for free support for Option types.

See here a generic version of ScaleMark where I commented out the custom proc we had before (it also demonstrates it working with Option as the label of a ScaleMark is optional):

The expanding "delete" button on the right is an issue I couldn't quite get rid of and stems from the toFormField of seq[T]. I think that's an acceptable sacrifice.

[PhilippMDoerner]

And just like that I think I cracked the last piece. We can now also generate forms for distinct types due to the newest toFormField proc.

Therefore we can fully auto-generate forms for the vast majority of nim-types. And if anybody wants to customize it, they can by simply overriding toFormField.

I guess any type that nim provides via magic would not be possible to represent like this. Further circular objects might just blow the entire thing up (I haven't tried yet, but I'd assume so). But those are special cases I'd say. Particularly for our current purposes. If we want to make this available for others we might have to deal with that.

[PhilippMDoerner]

Err maybe just for reference: I do not plan on doing anything else on this unless there's feedback, I'm happy with the current level this is at and can't see anything right now myself that I'd change.

Not sure if that was clear or not... I guess it makes sense to ask what typically indicates to you that a PR is not getting any further work done on unless there's feedback requests it :sweat_smile:

[PhilippMDoerner]

Anything else?

[can-lehmann]

Great work! :smile: