Is your feature request related to a problem? Please describe.
The interface PropertySource is used to add the ability to have properties to rules and renderers and some other things. The interface is pervasive in our codebase and is a problem:

• It's really not an interface, it's an abstract class, because it's so complicated to implement (and requires several fields) that if you implement PropertySource you have to extend transitively from AbstractPropertySource.
• This strengthens the same dynamic between Rule and AbstractRule, if you extend Rule you have to extend AbstractRule. If you want a delegate rule you need to delegate 20 methods from PropertySource.
• We can't replace PropertySource or make it evolve easily because every inheritor (every rule and renderer) is affected directly

Describe the solution you'd like

I think we would have much cleaner interfaces if we just renamed AbstractPropertySource to PropertyBundle (with the same functionality, but not abstract), and have the Rule interface have a method PropertyBundle getProperties(). We only need one implementation of the bundle.

Additionally, this allows us to implement custom PropertyBundle implementations, eg an IgnoredAnnotationsPropertyBundle which predeclares a property and adds nice getters. We can share property-related things between rules without having to put shared logic in a base rule class, which is more inflexible. This will also come in handy with language properties #2518.

Note that TreeRendererDescriptor already uses PropertySource in this way: instead of extending the interface it just uses an instance. I'd like to use the same model for #2518 and eventually for the large rule API restructuring needed for #3868

Describe alternatives you've considered

Additional context

• [core] Implementation plan for property framework changes #1432
• Removing getDysfunctionReason from PropertySource is related to [core] Simplify and improve rule configuration validation #3868