Add XOR (Exclusive OR) operator support for Bool type

[Lantua]

@GreatApe

But I am not sure that it's a strong argument to say that you can get by without it. You can get by without Bool.toggle() and Int.isMultiple(of:) too, and a lot of other convenient methods recently introduced.

If we're quoting them, we should at least compare their metric to the current (^) discussion.

For isMultiple(of:):

@John_McCall

Almost all library features can be composed from existing features with enough effort. To be considered for addition to the library, a proposed feature must satisfy two conditions: it must provide functionality that is useful to a substantial population of Swift programmers, and it must provide substantial advantages over the alternative ways of accomplishing that functionality. Potential advantages include:

• It may be complex, challenging, or error-prone for users to implement themselves.
• It may have substantial performance advantages over a user implementation, either because it has access to library internals or just because the library implementation will likely be more carefully tuned.
• It may be substantially easier to work with because it composes better with other language or library features.
• It may be substantially more "fluent": that is, more natural to discover, use, and read in code. The implementation may involve composing primitives in a subtle or tricky way, or the primitives may be unfamiliar to many programmers. This is a more subjective criterion than the others, and people may reasonably differ about how to apply it.

For toggle:

@Ben_Cohen

The core team sees the following motivations for its addition:

• commonality: the team felt that the need to toggle a nested boolean is a common one across multiple different problem domains
• readability: the addition of this command can significantly improve readability, especially as was seen in the example of toggling a boolean in a type held as a value in a dictionary
• consistency: while reproducing the method in user code is fairly trivial, it is good to have a consistent way of doing this across all swift codebases, rather than having multiple variants
• correctness: there is a correctness risk when the same long path needs to appear on both sides (especially when subscripts are involved), which this method would avoid
• performance: this didn’t come up during the review, but a mutating member operation will be more efficient (requiring only one subscript lookup) once we have the co-routine-based accessors, planned for a future release