Consider simplify syntax for common delegation patterns in `delegate_components!`

[soareschen]

Summary

In delegate_components!, it is common to wire up type or getter components that are defined using #[cgp_type] or #[cgp_getter]. For example:

delegate_components! {
    Person {
        ErrorTypeProviderComponent:
            UseType<anyhow::Error>,
        NameTypeProviderComponent:
            UseType<String>,
        NameGetterComponent:
            UseField<Symbol!("name")>,
        GreeterComponent:
            UseDelegate<new GreeterComponents {
                Formal:
                    GreetHello,
                Informal:
                    GreetHi,
            }>,
    }
}

Although the providers like UseType and UseField are quite consise already, there are still quite a bit of noise that makes developers hesitant to use CGP.

One way we can reduce the barrier is by making the delegation for types and getters even simpler, by supporting them with special syntax inside delegate_components!. For example:

delegate_components! {
    Person {
        type Error = anyhow::Error;

        type Name = String;

        getter name;

        GreeterComponent: UseDelegate {
            Formal:
                GreetHello,
            Informal:
                GreetHi,
        }
    }
}

This way, the implementation of abstract types would look like we are implementing an associated type.

For getters, it is not very clear what the correct syntax should look like. But something like above would help us shield the users from being exposed to the use of Symbol!, which is confusing for developers who seen type-level strings for the first time.

For UseDelegate, it helps to hide away the creation of an inner table, and allows users to focus on the main mapping.

Other Considerations

A main issue with the proposed syntax is that the import of component types like ErrorTypeProviderComponent and NameTypeProviderComponent become obscured by the macro. This makes it difficult to automatically import them, because IDEs like Rust analyzer does not provide the appropriate suggestion in the quick fix when the identifier originates from a macro.

It is also not clear whether this will make the delegate_components! macro become too magical. Alternatively, we may introduce this new syntax as a different experimental macro, to experiment on how effective is this in reducing the learning curve.