soc: apple: {sep,aop}: log the endpoints and services the firmware offers

[brentkearney]

Both drivers discard the coprocessor's own description of what it offers. This change logs it once per boot during probe(), at the same level as the RTKit syslog output these coprocessors already emit.

Changes

• sep.rs: enable the dev_info! in process_discover_msg() that prints each advertised SEPOS endpoint (four-character name and endpoint number), and the dev_warn! for unknown discovery message types. Restores the two constants they need, MSG_PARAM_SHIFT and MSG_PARAM_MASK.
• aop.rs: in register_service(), log the name and endpoint of any announced EPIC service that is not aop-audio, las, or als before returning.

dev_dbg! is not an option here: Rust's dev_dbg! routes to Device::pr_dbg(), which is gated on cfg!(debug_assertions) and does not participate in dynamic debug, so it compiles to nothing unless CONFIG_RUST_DEBUG_ASSERTIONS is set.

Why

The set of endpoints SEPOS actually starts has never been visible from Linux on any board, and AOP services with no driver leave no trace. Both lists are the first thing anyone working on these coprocessors needs. On an apple,t6000 / j316s MacBook Pro the SEP log prints:

Got endpoint Ok("cntl") at 0
Got endpoint Ok("hdcp") at 14
Got endpoint Ok("xars") at 16
Got endpoint Ok("xarm") at 19
Got endpoint Ok("hibe") at 20
Got endpoint Ok("pnon") at 21
Got endpoint Ok("stac") at 24

Testing

• Compile-tested against asahi-7.1.6-1 with rustc 1.93.1: drivers/soc/apple/sep.o and aop.o build before and after.
• CLIPPY=1 introduces no new warnings; rustfmt --check passes.
• The SEP output above was captured from the unpatched driver with a kprobe on the mailbox RX callback, not from a booted patched kernel.

Independent of #592; applies to asahi-wip in either order.