Refactor subsystem builder methods that can be properties

[johnjasa]

Multiple different methods in SubsystemBuilderBase could be properties to simplify their use. This is backwards incompatible though generally worthwhile; could deprecate the existing methods.

    @property
    def get_mass_names(self):

so it can be accessed as BatteryBuilder.get_mass_names instead of BatteryBuilder.get_mass_names(), since no arguments are used

Originally posted by @crecine in https://github.com/OpenMDAO/Aviary/pull/317#discussion_r1651562417

[crecine]

I don't think it is backwards incompatible, I'm pretty sure it still works with the parenthesis, they just aren't necessary anymore.

[jkirk5]

We could consider renaming them in this case. Builder.mass_names is pretty clean, but not backwards compatible. We will want to choose a "final" name for each method before 1.0

[Kenneth-T-Moore]

It might be better to go the other direction and give all of these methods a standard set of arguments that include aviary_inputs, phase name, and phase_info.

[jkirk5]

More arguments is probably best, since I'm sure users will have all kinds of odd subsystems that configure themselves based on different things. Having a subsystem need to know the value of specific inputs, or information on the mission is pretty reasonable and we should be able to provide that