Non-typedefed `enum` triggers assertion

If an enum is declared using `enum E { ... }` rather than `typedef enum { ... } E`, and subsequently used in function signatures (as `enum E`), this trips up a debug assertion in C2HS (if C2HS was compiled with `-O0`):
```
c2hs: Assertion failed
CallStack (from HasCallStack):
assert, called at src/Data/Attributes.hs:228:36 in c2hs-0.28.8-e-c2hs-e6bb2a89543eecd30d16b4e6e2ea12a66dd771967ff74bff199ee73788e9b564:Data.Attributes
```

Minimal working example:

`Mod.chs`:
```hs
module Mod where
#include
#c
enum E
{
V,
};
void foo(enum E);
void bar(enum E);
#endc
dummy = {#alignof size_t#}
```

`mwe.cabal`:
```cabal
cabal-version: 3.0
name: mwe
version: 0.0.0.0
build-type: Simple

library
exposed-modules: Mod
build-depends: base
build-tool-depends: c2hs:c2hs
hs-source-dirs: .
```

`cabal.project.local`:
```
package c2hs
ghc-options: -O0
```

- Doesn't happen if `-O0` is not specified, as `-O1` is the default in cabal, and asserts are erased then.
- Doesn't happen if `enum E` is only used once.
- Only triggers the next time `{# #}` block is evaluated (regardless of what that block is), hence the dummy.

Reproduce the minimal Mod.chs and cabal setup with c2hs built using -O0, then inspect src/Data/Attributes.hs at the assertion reported near line 228. Trace why repeated enum E uses in the function signatures leave the attributes state inconsistent when the later dummy block is evaluated. Done means the example completes without an assertion while preserving normal enum processing.

Written by the indexing model from the issue text.