Introduce new heuristics for block types

[soutaro]

Instead of making everything optional blocks, tries to infer if the block is optional or not based on the implementation.

1. If block_given? is called in the method, the block is optional
2. If the & var is tested in the method, the block is optional

Related to #1128

[soutaro]

@ksss How about this one? Seems like the example you put in #1228 can be correctly handled.

[ksss]

@soutaro Thank you for great implementation.

But I'm sorry. My example was too few.

I don't think the problem of ruby/gem_rbs_collection#16 as a real case has been solved.

For example, ActiveSupport::Callbacks::ClassMethods#set_callback in https://github.com/rails/rails/blob/18b5f24e274bd4318749d8287214f6f2bca9bcad/activesupport/lib/active_support/callbacks.rb , it calls ActiveSupport::Callbacks::ClassMethods#normalize_callback_params internally and #normalize_callback_params is It works with or without block. Naturally, #set_callback also works with or without block.

Thus, the propagation of the requirement for blocks should be taken into account.

In this modification, ActiveSupport::Callbacks::ClassMethods#set_callback outputs the block as required.