[flutter_adaptive_scaffold] Remove excessive `body` APIs.

[a-wallen]

Proposal

The AdaptiveScaffold APIs are unecessary. Consider the following fields in the AdaptiveScaffold constructor.

  const AdaptiveScaffold({
    // ...
    this.smallBody,
    this.body,
    this.largeBody,
    this.smallSecondaryBody,
    this.secondaryBody,
    this.largeSecondaryBody,
    this.bodyRatio,
    // ...
  });

1. There is nothing in the Material 3 Adaptive Spec that suggests that either the body or secondary body will adapt itself when the screen size changes, so why have a body and largeBody. The only place I can see this being useful is in the parameter's omission, not the supplementation.
2. The Scaffold itself should concern itself with global navigation elements, similar to that of the Scaffold API, but not local/detail elements that are inside the body. I believe that the original intent of the ${size}Body APIs to be configurable like a Canonical Layout, but I think that we should extract the implementation of a Canonical Layout into a separate widget.

[esDotDev]

As a general purpose Widget, AdaptiveScaffold would be more flexible and useful if all the bodies can potentially be adaptive, current incarnation of Material 3 spec notwithstanding.

[fredgrott]

Canonical Layouts are already a widget in the Microsoft dual screen package as the widget called TwoPane see:

https://pub.dev/packages/dual_screen

using it we write a screen based layout using the TwoPane api to handle two use cases: -Foldable hinge devices -non foldable devices Also flutter adaptive scaffold with two bodies will never be integrated with the Flutter sponsored Gorouter plugins as GoRouter only takes one child in shell routes and other scaffold enabled routes.