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

[ericastor]

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.