[enhancement] [DSLX] Require opt-in "unsafe" keyword to use timing-sensitive operations

### What's hard to do? (limit 100 words)

If we're writing code in DSLX, it's difficult to tell at a glance which code may contain timing-sensitive operations - and thus where we can't guarantee that the functional simulations (DSLX or IR interpreters at the function or proc level) will match the cycle-accurate simulations (block-level interpreters) or HW results.

### Current best alternative workaround (limit 100 words)

Users can continue to learn directly that they should be cautious when writing code that uses `recv_non_blocking`, as well as any future non-KPN operations we may introduce (e.g., `peek`, `try_send`, etc.).

### Your view of the "best case XLS enhancement" (limit 100 words)

Following Rust, make users opt into a lack of safety when writing procs that rely on non-KPN I/O operations, with something like an `unsafe` keyword that they can tag their proc - and fail to compile if they use an unsafe operation directly inside a safe proc.

If we go this route, then just as safe code can call unsafe code in Rust, safe procs should be able to spawn & otherwise interact with unsafe procs.