Resolve module_function visibility

[alexcrocha]

Closes #89 and finishes the singleton-method visibility resolution work started in #780/#781/#782. This PR resolves retroactive module_function visibility:

module Foo
  def bar; end
  module_function :bar
end

Foo.bar           # public singleton method
Foo.new.bar       # NoMethodError (private instance method)

Foo#bar becomes private and Foo.bar is added as a public singleton method.

One definition per side

The indexer emits two MethodVisibility definitions at the module_function :bar call site: one for Foo#bar and one for Foo::<Foo>#bar. The singleton-side definition uses the existing SINGLETON_METHOD_VISIBILITY flag; both carry Visibility::ModuleFunction.

The definitions must remain separate because reverse lookup maps each definition to one declaration. Giving each side its own definition lets invalidation detach the instance and singleton declarations independently when the source method or module_function call is removed. The flag bits are included in MethodVisibilityDefinition::id() so the two definitions at the same source location have distinct IDs.

Resolution

The instance-side definition follows the existing method-visibility path. The singleton-side definition looks for the same instance method, then attaches a declaration to the singleton class. Graph::visibility() exposes these as Private and Public, respectively.

The singleton class is created only after the target method is found. For module_function :missing, the instance side emits the diagnostic while the singleton side stays silent, leaving no empty Foo::<Foo> namespace behind.

The existing inline form (module_function def bar; end) is unchanged. Regression coverage verifies that its singleton companion can still be changed by a later singleton visibility call.

Known difference from Ruby

Rubydex resolves each argument independently. For module_function :a, :missing, it makes Foo#a private, adds the public Foo.a, and reports :missing. Ruby makes Foo#a private before raising, but creates no singleton copies for the call. Resolving independently preserves useful information while code is incomplete in an editor.

[alexcrocha]

• Resolve module_function visibility #802 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[vinistock]

Do we already support module function and the other visibility operations in the RBS indexer?

[alexcrocha]

I pushed a new commit simplifying the logic, which was a bit complex to grok. There's no more target/declaration owner split, and declaration creation is now next to the method match.

There's some duplication now, which is what I was trying to eliminate in the previous version. Let me know if this is more readable.

(Clippy complains that the function has too many lines. I'll fix it once we are happy with the shape of implementation)

[vinistock]

Looks good in general, I'm just wondering if we can unify the method visibility handling into a single loop