Rule Request: Properly unwrap "implicitly unwrapped optionals"

New Issue Checklist

• Updated SwiftLint to the latest version
• I searched for [existing GitHub issues] (https://github.com/realm/SwiftLint/issues)

New rule request

1. Why should this rule be added? Share links to existing discussion about what
   the community thinks about this.

Many of Apple's API's export "implicitly unwrapped optionals" instead of plain optionals. Usually because those APIs doesn't yet have null annotations. This is a footgun as Swift will not force you to properly unwrap it, which often cause crashes in production.

One example is EKCalendarItem#title, which exports var title: String! { get set }. It's very easy to just use it directly as event.title instead of doing event.title ?? "" or guard/if.

It would be great to have a rule that forces you to explicitly unwrap "implicitly unwrapped optionals" from imported frameworks. I don't think it should trigger on "implicitly unwrapped optionals" in the same file as that's usually intentional.

Some relevant discussion: https://forums.swift.org/t/disable-objc-bridging-as-implicitly-unwrapped-optionals/21966

2. Provide several examples of what would and wouldn't trigger violations.

Would trigger:

// event.title is EKCalendarItem#title

foo(event.title)

Wouldn't trigger:

foo(event.title ?? "")

guard let title = event.title else {
	return
}

foo(title)

3. Should the rule be configurable, if so what parameters should be configurable?

No

4. Should the rule be opt-in or enabled by default? Why?
   See README.md for guidelines on when to mark a rule as opt-in.

I would make it default as it helps catch a lot of potential crashes in production.

This should really be an opt-in warning in Swift, but it doesn't look like that will happen anytime soon:

• https://bugs.swift.org/browse/SR-223
• https://bugs.swift.org/browse/SR-104

Review README.md's opt-in rules guidance and the issue's examples and linked Swift discussions first. Done means a rule identifies direct use of implicitly unwrapped optionals imported from frameworks while allowing explicit coalescing or guard-based unwrapping, with its default or opt-in status resolved.