e2e: fold `simple_someip::e2e` into `simple_e2e`

[JustinKovacich]

Summary

simple_someip maintains its own E2E implementation in src/e2e/ while simple_e2e implements the same AUTOSAR profiles. Two crates carrying parallel type taxonomies for one protocol concept was agreed to be worth folding some time ago; this issue is to track that it has not happened and is now costing something concrete.

Current state

src/e2e/ still contains config.rs, crc.rs, e2e_checker.rs, e2e_protector.rs, error.rs, registry.rs, state.rs, and the crate has no simple_e2e dependency.

Consumers that have already moved to simple_e2e now straddle both taxonomies and need a bridge between them.

Why it matters

simple_someip::e2e::E2ECheckStatus is tagless; simple_e2e::CheckStatus carries a structured validate error with the byte-level detail. Bridging the two means synthesizing placeholder values for information the tagless type discarded — a CRC mismatch arrives as a mismatch with no observed and expected bytes attached.

That is a live debugging trap: the diagnostic looks present but is fabricated, so it misleads exactly when someone is trying to work out why a CRC check failed on the wire.

Proposal

As previously scoped:

• Delete src/e2e/{config, crc, e2e_checker, e2e_protector, error, registry, state}.rs and re-export the equivalents from simple_e2e.
• Keep E2EKey / from_message_id and the E2ERegistryHandle trait in transport.rs — those are SOME/IP-specific storage-policy glue, not algorithm, and have no home in a protocol-agnostic E2E crate.
• E2EProfile::Profile5WithHeader becomes a per-binding "include upper header" option rather than a third profile variant; worth getting right at the boundary so the three-variant enum isn't recreated upstream.
• Note e2e::Error splits into a protect error and a validate error, so the From impls in src/client/error.rs and src/server/error.rs each grow two variants rather than wrapping both in one umbrella — keeps the error chain flat and the diagnostic reachable.

Breaking?

Yes, for any consumer importing e2e::* types directly.

Sequencing

This is the largest of the current batch and the one that most wants to travel with the other breaking changes — #144, #145, #146 — in a single release rather than spending separate breaking bumps on each. #147 is additive and can land independently at any time.