While working on python#13531, I noticed that DataclassTransformer's
`collect_attributes` method was doing basically this:

```python
all_attrs = []
known_attrs = set()
for stmt in current_class:
    attr = convert_stmt_to_dataclass_attr(stmt)
    all_attrs.append(attr)
    known_attrs.add(attr.name)

for info in current_class.mro[1:-1]:
    if info is not a dataclass:
        continue

    super_attrs = []
    for attr in info.dataclass_attributes:
        # ...snip...
        if attr.name not in known_attrs:
            super_attrs.append(attr)
            known_attrs.add(attr.name)
        elif all_attrs:
            for other_attr in all_attrs:
                if other_attr.name == attr.name:
                    all_attrs.remove(attr)
                    super_attrs.append(attr)
                    break
    all_attrs = super_attrs + all_attrs
    all_attrs.sort(key=lambda a: a.kw_only)

validate all_attrs
```

Constantly searching through and removing items from `all_attrs`,
then pre-pending the superclass attrs will result in worst-case
quadratic behavior in the edge case where subtype is overriding
every attribute defined in the supertype.

This edge case is admittedly pretty unlikely to happen, but I wanted
to clean up the code a bit by reversing the order in which we process
everything so we naturally record attrs in the correct order.

One quirk of the old implementation I found was that we do not sort
the attrs list and move kw-only attrs to the end when none of the
supertypes are dataclasses. I tried changing this logic so we
unconditionally sort the list, but this actually broke a few of our
tests for some reason. I didn't want to get too deep in the weeds,
so opted to preserve this behavior.

While working on #13531, I noticed that DataclassTransformer's
`collect_attributes` method was doing basically this:

```python
all_attrs = []
known_attrs = set()
for stmt in current_class:
    attr = convert_stmt_to_dataclass_attr(stmt)
    all_attrs.append(attr)
    known_attrs.add(attr.name)

for info in current_class.mro[1:-1]:
    if info is not a dataclass:
        continue

    super_attrs = []
    for attr in info.dataclass_attributes:
        # ...snip...
        if attr.name not in known_attrs:
            super_attrs.append(attr)
            known_attrs.add(attr.name)
        elif all_attrs:
            for other_attr in all_attrs:
                if other_attr.name == attr.name:
                    all_attrs.remove(attr)
                    super_attrs.append(attr)
                    break
    all_attrs = super_attrs + all_attrs
    all_attrs.sort(key=lambda a: a.kw_only)

validate all_attrs
```

Constantly searching through and removing items from `all_attrs`,
then pre-pending the superclass attrs will result in worst-case
quadratic behavior in the edge case where subtype is overriding
every attribute defined in the supertype.

This edge case is admittedly pretty unlikely to happen, but I wanted
to clean up the code a bit by reversing the order in which we process
everything so we naturally record attrs in the correct order.

One quirk of the old implementation I found was that we do not sort
the attrs list and move kw-only attrs to the end when none of the
supertypes are dataclasses. I tried changing this logic so we
unconditionally sort the list, but this actually broke a few of our
tests for some reason. I didn't want to get too deep in the weeds,
so opted to preserve this behavior.