Remove trait bounds from generated program type's declaration

[regexident]

Fixes #23

[regexident]

Following up on #23 (comment) I've amended this PR to support the following (optional) syntax for specifying diverging impl trait bounds:

Non-diverging impl trait bounds

If only a generic struct is specified, then the macro will behave as is, using the provided type generics and bounds for both, the type's declaration, as well as its impls:

The following …

ascent!{
    struct AscentProgram<T> where T: Clone + Eq + Hash;

    // ...
}

… expands to something along the lines of this:

struct AscentProgram<T>
where
   T: Clone + Hash + Eq
{
   // ...
}

impl<T> AscentProgram<T>
where
   T: Clone + Hash + Eq,
{
   // ...
}

impl<T> Default for AscentProgram<T>
where
   T: Clone + Hash + Eq
{
   // ...
}

Diverging impl trait bounds

If both, a generic struct, as well as an impl … are specified, then the macro use the provided type generics and bounds for the type's declaration, as well as the impl Default, while using the provided impl generics and bounds for the type's impls:

The following …

ascent!{
    struct AscentProgram<T> where T: Clone;
    impl<T> AscentProgram<T> where T: Clone + Eq + Hash;
    // ...
}

… expands to something along the lines of this:

struct AscentProgram<T>
where
    T: Clone
{
   // ...
}

impl<T> AscentProgram<T>
where
   T: Clone + Hash + Eq,
{
   // ...
}

impl<T> Default for AscentProgram<T>
where
    T: Clone
{
   // ...
}

Impl-only trait bounds

Similarly the following …

ascent!{
    struct AscentProgram<T>;
    impl<T> AscentProgram<T> where T: Clone + Eq + Hash;
    // ...
}

… expands to something along the lines of this:

struct AscentProgram<T> {
   // ...
}

impl<T> AscentProgram<T>
where
   T: Clone + Hash + Eq,
{
   // ...
}

impl<T> Default for AscentProgram<T> {
   // ...
}

[s-arash]

We should also disallow custom impl signatures on ascent_run and ascent_run_par. This could be done at the start of the compile_mir function.

[s-arash]

Hi @regexident, and thanks again for the PR!
Do you have time to fix the remaining errors in this PR? If not, let me know and I can take it from here.

[regexident]

I'll try to give it a go tomorrow or the day after.

[regexident]

@s-arash Looks like the experimental "attrs on relations" in AscentProgram got broken my changes of the Signatures type.

The handling of attritibute parsing within impl Parse for AscentProgram { … } looks a bit shady to me (leaky abstraction) since any changes within Signatures should not break the parsing of the outer AscentProgram.

I'm not sure how to best address this. Feel free to take it from here, if you do.

[s-arash]

The handling of attritibute parsing within impl Parse for AscentProgram { … } looks a bit shady to me (leaky abstraction) since any changes within Signatures should not break the parsing of the outer AscentProgram.

It wasn't changes to Signatures that broke parsing, it was unnecessary changes to AscentProgram parsing that broke AscentProgram parsing!