Rule Request: Warn on assigning nil to IUO.

New Issue Checklist

• Updated SwiftLint to the latest version
• I searched for existing GitHub issues

Rule Request

1. Implicitly Unwrapped Optionals are common to use for late initialization. For instance this is done by the IBOutlet properties generated by Interface Builder.
   When just using IUOs for doing late initialization, it is unusual to re-nil these properties.
   This means that doing so could often be a programmer error.
   For instance it is common to assign nil-values to UILabel text in 'prepareForReuse' in a UITableViewCell. It is a rather easy typo to nil the label instead of the text property of the label.
   This gives an error that will trigger once the cell is reused, since the IUO is now nilled.
   If it is possible to detect nil-assignments to IUOs, it seems like this sort of error could be prevented in many cases.
   As we have not been able to think of a valid reason to re-assign nil to an IUO, it sounds like it could be a reasonable default to have such assignments trigger a warning.

var a: Int!
var b: Int?
a = 1 // would not trigger the violation
a = nil // would trigger the violation
b = nil // would not trigger the violation

3. No configuration required.
4. We believe that it should be enabled by default. Unless someone can provide a reasonable programming pattern where assigning nil to an IUO after late initialization makes sense.

Start with the issue's Swift examples: assignments of nil to an implicitly unwrapped optional should be violations, while non-nil assignments and nil assignments to ordinary optionals should not be. Review SwiftLint's rule entry points and tests to find where a new default-enabled rule belongs, then add coverage for these cases.