support resId in the way that makes sense

[atsushieno]

Currently property values are stored without paying any attention to resId. But having one single value for a property seems fundamental mistake. When resId is involved, the property values are stored like a map. juce_midi_ci has the same problem. Common Rules for PE specification itself is indeed problematic by stating almost nothing about resId. There is no access to what kind of resId is available, especially to clients.

[atsushieno]

• updating property value from client request should involve resId and requireResId
• updating property value locally should involve resId and requireResId
• subscription should be keyed with both resource and resId
• retrieving property value without resId should be prevented when requireResId is true

[atsushieno]

55a4f9d started some resId related changes.

[atsushieno]

I'm rather thinking, current PropertyValue should become abstract and current one should become a specialized one like CommonRulesPropertyValue. It comes with a problem on serializability though.

We should probably "serialize" the configuration itself just as UMP bytes. But that's going to be another issue (that may be first to resolve though).