Stop ignoring irb in RBI generation

[KaanOzkan]

Motivation

Since sorbet/sorbet@2f9fbc2 superclass mismatch between IRB's tapioca generated RBIs and the sorbet payload can be resolved by using the new flag with the appropriate class name,
--suppress-payload-superclass-redefinition-for=Foo.

This flag can be added to sorbet/config.yml for convenience.

Implementation

Tests

[st0012]

While the flag is certainly a great improvement, I think devs will need to manually type something like --suppress-payload-superclass-redefinition-for=OldClassName for every single class that has a mismatch?
If that's the case, I fear it'll still be a huge pain for devs as we're going to do mass superclass renaming with PRs like ruby/irb#873 this year.

[KaanOzkan]

@st0012 Most renamings should be fine but if there are plans to change superclasses then yes I'm happy to keep ignoring it until it's done. irb is not commonly referenced so dealing with superclass mismatches are probably not worth having the RBIs. If there are constants that may be common we could put them as annotations in rbi-central so that they don't have to be manually shimmed. Maybe something similar to what we have in our monolith?:

module IRB
  VERSION = T.let(T.unsafe(nil), String)

  class Statement
    class Command < Statement
    end

    class Expression < Statement
    end
  end
end

[st0012]

Maybe something similar to what we have in our monolith?:

It's only needed in Core because of the debugging patches, which I imagine most apps wouldn't have. So I don't think it's worth adding those to rbi-central either.

IMO, before IRB's command/helper method extensions are released and adopted in Shopify apps like Core, we don't need to generate its RBIs through Tapioca nor have annotations in rbi-central.