`Attribute#ivar_name` API is unclear

The #ivar_name attribute of each RBS::Members::Attribute* class can return one of 3 things:

# ivar_name will return `nil`, which indicates the default (@a) is inferred
attr_reader a: Integer

# ivar_name will return `:something_else`
attr_reader b(@something_else): String

# ivar_name will return `false`
attr_reader c(): bool

This has a few downsides:

1. The distinction between nil and false is subtle and non-obvious

2. Most callers (e.g. a type checker, LSP, etc.) probably care about the instance variable name regardless of whether it was inferred or explicit, and will have to compute it themselves when they get nil.

3. The RBS type of this field is complex:
   https://github.com/ruby/rbs/blob/3fc6b05588e9378a387fca1caad58a75076dd90c/sig/members.rbs#L177

   • This will also makes the C API less clear, since the type has to be some general node type (e.g. rbs_node_t *), rather than specifically a symbol type (rbs_symbol_t * or NULL).

I propose we deprecate this field, and come up with an easier-to-consume alternative.

Start with the RBS::Members::Attribute* definitions and sig/members.rbs around the ivar_name field. Review the issue's examples and consider how type checker, LSP, and C API callers would consume an alternative; done means agreeing on and documenting a clearer replacement and deprecation path.