Align sharding more like Dagger

[ZacSweers]

After looking more at how Dagger does sharding, Metro's have a somewhat custom implementation that's less beneficial. We should make metro's

• be static sibling classes instead of inner
• keep an instance in the parent graph
• make the shard hold provider fields directly, rather than initializing them in parent graphs. Eliminates the need for the reverse irSetField call
• can hold multibinding accessor properties

Would want to add a receiver to CollectedProperty to support this indirection so later graph expression generation can call it on the right property (either a provider property or shard's property)

[ZacSweers]

CC @IzanRodrigo

[ZacSweers]

I started working on this in main...z/shardingWork, but I'm not thrilled with how weedy it's getting and going to do some refactoring on main first. I'll probably also hide sharding support from the gradle DSL API and omit it from release notes for now as I don't think it's ready

[ZacSweers]

Higher level plan

• Want to refactor provider property handling to be more detailed than just IrProperty, and instead work with something like a ProviderBindingProperty that has a reference to its owning shard and field within it. A shard in turn is with the enclosing graph or a shard class that is parented by a graph class. Then users of these would invoke the full path to the property in the parent
• ProviderBindingProperty could then also have an IR function to invoke its access, which should make adding something like SwitchingProvider easier in the future since it becomes an implementation detail
• Want to make BindingLookup be context-aware, allowing it to disambiguate usages of instances and providers in extensions better