[embedded] Make RNG APIs available on embedded Swift

[kubamracek]

• Make SystemRandomNumberGenerator, .random(), .random(in: ...), .randomElement() APIs available in embedded Swift.
• Add tests exercising those.
• Add a test that checks the symbol dependencies of program that use the random APIs, the only added dependency should be on a (relatively standard and commmon) arc4random_buf.

[phausler]

are these functions weak? e.g. if I implement swift_stdlib_random in a platform definition to a non-cryptographic-secure-pseudo-random source but want to not claim arc4random_buf is implemented would that work?

[kubamracek]

This is a good point, and I was previously thinking that we would just have Embedded Swift have a small fixed set of well-known basically-always-present-anyway dependencies, but I do see your point that it would really be useful to have more influence and control over things like this.

I don't think Swift has a notion of weak / override-able functions... does it? Though TBH even if it did, the linker based weak function replacement is arguably quite non-obvious and "too magical". I was thinking that an explicit solution would be better, something along the lines of:

public enum EmbeddedConfiguration {
  // default is arc4random_buf...
  public static var randomnessSource: (@convention(c) (UnsafeMutableRawPointer, Int) -> ()) = arc4random_buf
}

public func swift_stdlib_random(_ buf: UnsafeMutableRawPointer, _ nbytes: Int) {
  EmbeddedConfiguration.randomnessSource(buf, nbytes)
}

// ...but the user can change it by simply doing this in the firmware startup code:
EmbeddedConfiguration.randomnessSource = my_other_randomness_provider

[kubamracek]

@swift-ci please test

[kubamracek]

@swift-ci please test

[kubamracek]

@swift-ci please test

[rauhul]

good enough for now, I'd like the link time error to be missing "swift_stdllib_random" but we can improve this later

[kubamracek]

@swift-ci please test