Add Rules to Support Ray Wenderlich's Swift Style Guide

It would be great if SwiftLint supported Ray Wenderlich's Swift Style Guide:

• Variable Names: Use camel case.
• Function Names: Use camel case.
• Class Names: Use upper camel case.
• Function Arguments: Prefer named parameters, unless the context is very clear.
• Enumerations: Use upper camel case.
• Spacing: Indent using 2 spaces. Should be parametrizable, and probably 4 by default.
• Opening Braces: Always open on the same line as the statement.
• Closing Braces: Close on a new line.
• Spacing Between Functions: Leave exactly one blank line between functions. This should probably also apply between structs, classes, etc. Should be parametrizable.
• #5828
• Access Modifiers: Don't repeat the access modifier when overriding a method.
• Protocol Conformance: When adding protocol conformance to a class, prefer adding a separate class extension for the protocol methods.
• Computed Properties: If a computed property is read-only, omit the get clause. The get clause is only required when a set clause is provided.
• Closure Expressions: Use trailing closure syntax only if there's a single closure expression parameter at the end of the argument list.
• Types: Prefer Swift's native types over Objective-C types (e.g. use Double instead of NSNumber).
• Constants: Always use let instead of var if the value of the variable will not change. Supported by compiler.
• Naming Optionals: Avoid names like optionalString or maybeView, since optionalness is already captured in the variable's type. (Prefer using the same name: if let subview = subview { ... }.)
• Initializing CGGeometry: Use native Swift struct initializers (e.g. let bounds = CGRect(...) instead of let bounds = CGRectMake(...)).
• CGGeometry: Prefer struct-scope constants CGRect.infinite, CGRect.null, etc. over global constants CGRectInfinite, CGRectNull, etc.
• Syntactic Sugar: Prefer shortcut versions (var deviceModels: [String]) instead of the full generics syntax (var deviceModels: Array<String>).
• For Loops: Prefer the for-in style instead of the for-condition-increment style.
• Semicolons: Do not use semicolons after each statement (i.e. no trailing semicolons).
• #5829

Probably Not Worth It

• Type Inference: Let the compiler infer the type for a constant or variable, unless you need a specific type other than the default (e.g. avoid let message: String = "Click the button."). -> There are probably many valid reasons to break this rule.
• Self: Avoid using self except when required by the compiler or for disambiguating property names from arguments. -> This seems very difficult to verify.
• Comments: Avoid block comments inline with code, as the code should be as self-documenting as possible. -> There are many excellent reasons to use block comments inline with code.
• Spacing Within Functions: Too many sections means you should refactor. -> This is effectively satisfied by the function_body_length rule.
• Prose (Comments): When referring to functions, include the required parameter names or _ for unnamed parameters. -> Not worthing trying to style-check comments.
• Class Prefixes: Types are namespaced by the module that contains them, so class prefixes should not be added to member variables or functions. -> How could SwiftLint identify a class prefix?

No files, tests, or entry points are named. Review the unchecked items against SwiftLint's existing rules and the referenced issues #5828 and #5829, then narrow the request to a specific rule with a defined completion condition.