[cxx-interop] Add CxxStack protocol for std::stack ergonomics.

[CrazyFanFan]

This adds a protocol to the C++ standard library overlay that will improve the ergonomics of std::stack when used from Swift code.

As of now, CxxStack adds a top() -> Element function to C++ stacks.

[j-hui]

@swift-ci please test

[j-hui]

Thanks for your contribution @CrazyFanFan ! I left some preliminary comments for now

[j-hui]

nit:

Suggested change

	StackOfInt initEmtypeStackOfCInt() {
	StackOfInt initEmptyStackOfCInt() {

[j-hui]

This protocol should be documented

[j-hui]

Why not return an optional value instead of asserting this pre-condition here?

[CrazyFanFan]

Thanks for the feedback!

1. In C++, accessing the top of an empty stack is undefined behavior, so a similar effect is retained here.
2. Considering bridging to Swift, using an optional value is indeed a good option.

I've been torn between these two approaches.

[j-hui]

The behavior of calling pop() (which calls pop_back() on the underlying container) is undefined for empty() stacks. I'm wondering then if that warrants either (1) this method being marked unsafe, and/or (2) wrapping this method with something like:

/// Return value indicates whether an element was successfully popped
mutating func safePop() -> Bool {
  if empty() {
    return false
  }
  __unsafePop()
  return true
}

(with a better name than safePop())

[CrazyFanFan]

1. Oh, thanks for the reminder. It's more reasonable to mark this method as unsafe.
2. I think safePop is concise and clear enough. I'll enhance its implementation.

[hnrklssn]

Someone more familiar with Swift than me would have to comment on what the "swifty" way would be, but if we're providing a safe wrapper anyways, do we perhaps want to return Element? containing the removed value, rather than just a boolean?

[CrazyFanFan]

Yes, I've added a mutating func safePop() -> Element?. Currently, some tests are failing, and I'm in the process of debugging.

[hnrklssn]

I think it would be good with some negative test cases for inferring conformance, just to make sure it gets handled properly. In particular I'm interested in how element types that are ~Escapable and/or ~Copyable are handled. Do they get a diagnostic, or is the conformance just omitted? Also, can std::stack be declared for forward declared types in C++? If so, it'd be good to have a test case for that too.