[stdlib] refactor precondition() for consistency

[glessard]

The following simple function currently compiles differently in -Onone mode than in -O or -Osize:

func example(i: Int?) -> Int {
  if let i { return i }
  precondition(false)
}

Compilation succeeds in -Onone, and fails otherwise (with a missing return value error.)

This is due to the implementation of precondition() being @_transparent, and having two completely different implementations depending on whether it takes the _isDebugAssertConfiguration() branch or the _isReleaseAssertConfiguration() branch. The version of precondition() that is analyzed by the compiler after the mandatory inlining is simply different whether it occurs in debug mode or in release mode.

In debug mode, the precondition's condition is explicitly used for flow control, and _assertionFailure is called conditionally. In release mode, the precondition's condition result is saved in a variable, then Builtin.condfail_message is called unconditionally. In the particular case show above, where precondition() is called with a constant false argument, this difference in approaches causes a compilation error in release mode that doesn't occur in debug mode.

The solution is to use the condition for flow control before deciding on the specific way to trap.

Resolves rdar://106320129

[glessard]

@swift-ci please test

[glessard]

@swift-ci please test linux platform

[glessard]

@swift-ci please test

[glessard]

Note: making a similar change to the internal _precondition() caused tests/SILOptimizer/reverse-array.swift to fail on Linux due to a llvm.trap call being not optimized out. While that test did not fail on macOS, it is not clear that the proposed change won't cause a regression in codegen quality.