Improve ergonomics

[ericlewis]

It's hard to remember all of the configuration methods. Sometimes they aren't so obvious in isolation (what is preferring a grabber visibility deep in this component hierarchy?). It's hard to discover the apis for quick configuration. I am leaning towards something similar to environment(_, _). Like this:

Text("hello")
  .sheet(\.prefersGrabberVisible, true)
  .sheet(\.detents, [.medium()])

The sheet method name makes sense, but other ideas should be considered as well:

• .presentation(...)
• .pageSheet(...)
• .presentationPreference(...)
• .sheetPreference(...)

There isn't really much prior art around organized interaction with Preferences aside from creating bespoke methods like environment interactions.

I will note that using preferences the KV way doesn't make it completely obvious that we are moving upwards like a typical preference setting might. Likely important to keep preference somewhere in the signature.

Another useful tool may be a property wrapper to be able to read from preferences:

@Preference(\.pref)
var pref 

This opens the potential for simplifying the entire configuration pipeline.

Food for though 🍎

[ericlewis]

Result of the investigation was to use enums & associated values:

struct SheetContentView: View {
  var body: some View {
    Text("Hello World")
        .sheetPreference(.grabberVisible(true))
  }
}

This satisfies the following:

• Easy to remember, understand without context, and provides useful code completion.
• Can be extended to provide new and tangential configuration options

The reason enums are used instead of key paths is that there is no equivalent struct to EnvironmentValues for preferences. It wouldn't really make sense to have one either, since preferences aren't consolidated that way. Enum provides most of the same functionality and shape as the KeyPath api.