Optimise the Swift version of Vexilla Client

[Joannis]

1. Move SwiftPM's Package.swift into the repo's root. This is required for SwiftPM projects to depend on this package.
2. Add a VSCode recommendation for the SSWG plugin
3. Remove inline API call implementations, which leans on URLSession. API calls are extracted into a new test-wide implementation.
4. Adopt XCTAssertGreaterThan-family of functions for comparing values
5. Support unicode characters in String hashing algorithm, also optimises the algorithm slightly - reducing memory copies.
6. Add concrete error types, replacing some String errors.
7. Remove safeGet and all code that leveraged this.

• Moved JSON parsing over to JSONDecoder
• Accessing dictionaries now uses the subscript
• This allows errors to be added for specific scenarios
• Reduce cyclomatic complexity through guard statements

cmgriffing: editing this description to hopefully kick of the github action (x3)

[netlify]

👷 Deploy request for forms-vexilla pending review.

Visit the deploys page to approve it

Name	Link
🔨 Latest commit	3381137

[netlify]

👷 Deploy request for auth-vexilla pending review.

Visit the deploys page to approve it

Name	Link
🔨 Latest commit	3381137

[CLAassistant]

All committers have signed the CLA.

[cmgriffing]

The "PR Test / test-swift" job seems to be failing.

Here is the first error that gets repeated a bunch.

/__w/vexilla/vexilla/clients/swift/Sources/VexillaClient/Types.swift:85:33: error: expected ',' separator
  public init(from decoder: any Decoder) throws {

The second error that repeats a lot with slight variations is:

/__w/vexilla/vexilla/clients/swift/Sources/VexillaClient/Types.swift:253:62: error: cannot infer contextual base in reference to member 'value'
      let value = try container.decode(String.self, forKey: .value)

[Joannis]

Right, Swift toolchain difference. I forgot about some of these language features having been added more recently.

[cmgriffing]

Not sure why the tests didn't kick off when you updated it. That is a bug on my end in the workflow. However, after an edit of the description of the PR, I was able to kick it off again and the tests now pass inside of the container.

[cmgriffing]

suggestion (blocking): I would prefer not to move the Package.swift file to the top level. With plans for 14 SDKs, the root level of the project could become unwieldy if all clients SDKs did this.

Does having the Package.swift in a nested folder break something for SwiftPM?