Refactor select to not create objects

[lredlin]

The use of a SelectCase object was making specifying select harder because it requires managing heap state.

The new implementation takes the channel reference, direction (SelectSend/SelectRecv), and value directly as parameters to the select functions. This eliminates the need to construct and manage intermediate case objects on the heap. The downside is that there are parameters and return values that aren't used depending on whether it it a send or receive.

Key changes:

• Split single Select1/2/3 functions that took a blocking bool parameter into separate NonBlockingSelect1/2/3 and BlockingSelect1/2/3 functions for clarity
• These functions now accept channels, directions, and values directly as parameters
• Return values are now tuples: (selected/caseIndex, received_value1, received_value2, ..., ok)
• For send cases, the value is sent; for receive cases, the value parameter is ignored
• Simplified case selection logic:
  • Blocking select: continuously tries randomly selected cases
  • Non-blocking select: picks a random starting case and tries all cases in order using modular arithmetic wraparound
    => No permutation generation or duplicate-checking logic needed
• Removed Select4 and Select5 variants - if needed, we will implement a generic Select-N directly in Goose rather than continuing to add hardcoded variants since these blow up in scope and I suspect that select statements this large will be rare in the wild

Perennial regoose PR: mit-pdos/perennial#393

[tchajed]

Looks good to me. I'm a little surprised the structs don't help, but maybe combining using them for inputs and outputs was not useful, and a struct isn't needed for just direction & value.

BlockingSelect3 looks like it'd be pretty complicated to reason about due to the complex control flow. Might be easier to do blocking select in GooseLang over a list for all N, use recursion directly. But I'm happy to merge this in the meantime while you experiment.