feat: support generics with define_language macro

[kayagokalp]

Description

Before this PR, it was not possible to define generic Language using define_macro because the macro itself was not parsing the generic part. So the following code piece was failing:

define_language! {
    pub enum GenericLang<T: SaturationNumber> {
        Number(T),
        "+" = Add([Id; 2]),
        "-" = Sub([Id; 2]),
        "/" = Div([Id; 2]),
        "*" = Mult([Id; 2]),
    }
}

Where SaturationNumber is a super trait of required set of traits such as FromStr, Debug, Display etc. This PR adds the required parsing patterns to the macro so that it is possible to define such language enums, using the macro easily. I added a test to showcase both that:

1. The macro can parse generics.
2. The macro can apply bounds (to generic type) correctly by testing an implementation of a bound that is definitely going to be satisfied for any T that the language is generic over (Display).

Docs are updated to showcase new generic language usage.

Motivation

I wanted to make my language generic over the number type. So that I can easily switch between different custom number representations to experiment with the effect on saturation performance given that some implementations are going to be faster to work with, saturation might be able to cover a larger space and I wanted to observe the effect experimentally without needing to re-implement same language. But in more general it should be useful to anyone who requires to define a language generic over a type.

[mwillsey]

Cool idea! I think it would be simpler without the bounds, right? Why do you need to constrain the definition of the enum? AFAIK, that's typically not needed, it's instead preferred constrain impls.

[kayagokalp]

Cool idea! I think it would be simpler without the bounds, right? Why do you need to constrain the definition of the enum? AFAIK, that's typically not needed, it's instead preferred constrain impls.

Thanks for the comment! that is a very valid point, in my experience as well, what I generally feel is that it is not required to constrain the definition itself and constraining the implementation is preferred. I have only found constraining the definition useful for pieces that will be consumed by downstream to impose a tighter contract where the type itself is not available to even "construct". For the use cases of egg this might not be relevant as i feel the consumer's of egg crate would tend to be binaries rather than library crates.

My main motivation was that to allow valid rust syntax to be accepted by the macro. So this implementation still supports bounds on definitions, and also generics without bounds. Of course if maintainability of the macro itself is preferable to this flexibility I can remove the bounds on definition support

[mwillsey]

I would prefer removing the bound support to simplify the macro for now.