Add Process.on_interrupt

[HertzDevil]

Resolves #12224. The "interrupt" corresponds to Ctrl+C and Ctrl+Break for Windows console applications. The following will now work:

# press Ctrl+C or Ctrl+Break 5 times to exit

count = 5
Process.on_interrupt do
  print(count -= 1)
  exit if count == 0
end

while true
  print '.'
  sleep 1
end

It also means that specs will abort gracefully when interrupted, whether from a spec executable or via crystal spec.

The following does not work:

Process.on_interrupt { print '.' }

while true
  # `STDIN.gets` is synchronous, and the outcome depends on the signal plus the handler:
  #
  # * Ctrl+C, custom handler: `x == nil`, and the handler is not called
  # * Ctrl+Break, custom handler: `x == nil`, and the handler is not called
  # * Ctrl+C, interrupts ignored: `x == nil`
  # * Ctrl+Break, interrupts ignored: `x == nil`, but the process exits briefly afterwards anyway
  # * default handling: process exits before `STDIN.gets` returns
  x = STDIN.gets
end

Additionally, the bin\crystal.bat and bin\crystal.ps1 wrappers do not use some kind of exec (PowerShell 7.3 added Switch-Process but it is unavailable on Windows itself!), so if a custom interrupt handler returns normally without exiting the process, control returns to the console but the process will continue running in the background. This isn't a problem for crystal spec as specs are run inside an at_exit.

On Windows, this interrupt handler is run on a fresh thread every time an interrupt arrives, so some form of synchronization is required. Originally the plan was to integrate this into the event loop, but the current implementation uses an atomic counter instead, and the listener loop fiber on the main thread simply polls for any outstanding interrupts every 50 milliseconds. This seems to be a good compromise because e.g. IO::FileDescriptor#flock_* does the same thing.

[straight-shoota]

I suppose these handlers could also be placed in a portable interface? But this can be added later.

[straight-shoota]

We can leave it out of the scope of this PR, but would it be feasible to implement Signal::INT.trap as Process.on_interrupt on Windows?