docs(examples): simplify docs using new layout methods

[joshka]

Use the new Layout::horizontal and vertical constructors and
Rect::split_array through all the examples.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (23f6938) 92.3% compared to head (48b5ffa) 92.3%.

Additional details and impacted files

@@           Coverage Diff           @@
##            main    #731     +/-   ##
=======================================
- Coverage   92.3%   92.3%   -0.1%     
=======================================
  Files         55      55             
  Lines      14840   14836      -4     
=======================================
- Hits       13703   13699      -4     
  Misses      1137    1137             

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[joshka]

Waiting on #729 to be finalized for naming.
Rebase after.

[joshka]

Removed the helper methods. They don't make things particularly clearer and have problems with polluting the imports. They're tough to put in the prelude due to the common names (min/max/length), which overall suggests that we're better without them. Diff when removed was 254 lines added, 258 removed, so the benefit on LoC is negligible.

[joshka]

Rebased on the current version of main with Rect:split()

[joshka]

Regarding testing this, the easiest way is to run makers run-examples which runs each example one after the other. All still work fine.

[joshka]

Rebased now that #729 is merged.

[Valentin271]

Looks good, I can confirm all examples are working and layouts are visually ok.

[kdheepak]

I think it is a little confusing that we have

let rects = layout.split(area);

and we also have

let [rect1, rect2] = area.split(layout);

Is there a reason we couldn't always use the second form?
If there is a good reason for choosing the first form, I think at the very least it should be documented on the website.

[joshka]

Is there a reason we couldn't always use the second form? If there is a good reason for choosing the first form, I think at the very least it should be documented on the website.

The area.split(layout) form requires knowing the number of rects that will be returned beforehand. The layout.split(area) form does not. The places where I've left that are places where there are a dynamic number of areas in which to split to.

I also left a couple of more complex examples alone (IIRC it was in the old demo).

You're right - this could do with some docs in Layout::split - another PR perhaps?