`features = ["std", "elf32"]` doesn't build

While trimming down my dependencies, I noticed that building Goblin with `default-features = false, features = ["std", "elf32"]` fails:

```
Checking goblin v0.6.0
error[E0432]: unresolved import `crate::elf64`
--> /Users/mjk/.cargo/registry/src/github.com-1ecc6299db9ec823/goblin-0.6.0/src/elf/header.rs:249:17
|
249 | use crate::elf64;
| ^^^^^^^^^^^^ no `elf64` in the root

error[E0433]: failed to resolve: could not find `elf64` in the crate root
--> /Users/mjk/.cargo/registry/src/github.com-1ecc6299db9ec823/goblin-0.6.0/src/elf/dynamic.rs:802:35
|
802 | elf_dyn_std_impl!(u64, crate::elf64::program_header::ProgramHeader);
| ^^^^^ could not find `elf64` in the crate root

Some errors have detailed explanations: E0432, E0433.
For more information about an error, try `rustc --explain E0432`.
```

This isn't a big deal – I can add `elf64` to the feature list – but the Rust Book [advises against it](https://doc.rust-lang.org/cargo/reference/features.html?highlight=additive#feature-unification):

> A consequence of this is that features should be _additive_. That is, enabling a feature should not disable functionality, and it should usually be safe to enable any combination of features.

Start with the feature-gated code in src/elf/header.rs and src/elf/dynamic.rs, then reproduce the reported configuration with default-features = false and features = ["std", "elf32"]. Trace why those paths reference crate::elf64; done when that dependency combination checks successfully without adding elf64.

Written by the indexing model from the issue text.