Refactor and unify new attribute parsing

[tyranron]

Synopsis

In the recent PRs, reworking AsRef/AsMut, Debug, Display, From and Into macros, the new approach was introduced for attributes parsing: attributes are parsed as dedicated types, representing each attribute. However, due to lack of a single machinery to do so, it brought a lot of boilerplate and code duplication. Utterly, the parse_attrs() logic is fully repeated for each attribute type. This also lead, that the same attribute type (like skip of forward) is implemented twice in different macros, leading to some hardly noticeable behavior differences. This was partially fixed in those previous PRs by extracting some repeated attributes to utils module, but this is not enough.

Solution

This PR introduces utils::attr module, which serves and provides the following:

• ParseMultiple trait machinery, which represents an extracted and abstracted parse_attrs() approach, and DRYes all the attributes' implementations by eliminating boilerplate. Now, implementing a custom attribute parsing only requires specifying behavior deviating from the default one, everything else is there already.
• Extracted commonly used attributes, like skip, forward, (<types>), repr, etc, so they can be easily reused in different existing macros and in future implementations.
• Either implementation for ParseMultiple, which allows simply combine different attributes in Either<OneAttribute, AnotherAttribute> way without introducing new types and implementations for it.

Additionally

Removes parsing::Type. The parsing::Expr was introduced to avoid using syn/full feature for syn::Expr, as it blows compilation times. Later, similar parsing::Type was introduced instead of syn::Type. However, syn::Type doesn't require a syn/full feature to work fully and properly, and so, we can just use syn::Type and don't bother.

Checklist

• Documentation is updated
• Tests are added/updated
• CHANGELOG entry is added (not required)

[tyranron]

@JelteF ping

[tyranron]

@JelteF ping

[JelteF]

Looks fine to me, only note is that total line count actually got larger with this PR

[tyranron]

@JelteF yup, because generic code usually requires more lines when declared. However, the actual code duplication was largely reduced, and it should show even more reusage in subsequent PRs.