We used to treat methods that didn't have a source location the same as
methods that explicitly were not defined in the current gem. That
resulted in Tapioca creating more method definitions than necessary.

We would only skip method generation for a method if the constant it was
on was an ignored type (i.e. a built-in type), so that we wouldn't keep
redefining methods for built-in types. However, for all other types,
especially types that come from other gems, we would just keep on
generating all the methods regardless of if they were defined by this
gem or not.

Moreover, the source location check was happening at the wrong location,
before unwrapping the method signature. Thus, many methods with
signatures would not be generated when the previous problem was fixed,
since our code would see them as being defined in Sorbet runtime.

The fix is to return a more fine-grained result from `method_in_gem?`
which signals yes/no/don't-have-source-location. Based on that we can
skip generating don't-have-source-location cases if they are for
built-in types and totally ignore the methods that have a source
location and are definitely not defined in the current gem.

Additionally, if we try to unwrap the method signature and we get an
exception, that means the signature block raised an error. If we
continue with the method as is, the source location checks would think
the method definition does not belong in the gem (since the method is
still wrapped), and we would thus skip the method generation. To avoid
that, the `signature_for` method is now raising a custom exception to
signal that exceptional case, so that we can at least continue
generating "a" method definition.