Fix issue with input rate policies

[cpsievert]

See #2387 for a motivating example. In that example, the slider starts off with the correct Debouncer input rate policy, but when the slider is updated, it's policy changes to the default Invoker (i.e. immediate) rate policy.

It seems this happens because InputRateDecorators's $ensureInit() method is called with a name that contains both the input id and type. As a result, when the type of an input changes, it fails to look up the input rate policy and ends up defaulting to Invoker() instead.

[alandipert]

In the original code, the explicit contribution of type to the setInput() key in addition to id makes me wonder if this is removing some historical feature.

Is it possible that having multiple inputs with the same ID, but different types, is a thing someone would do for some reason?

If we can rule that out then this seems like solid improvement.

[cpsievert]

Is it possible that having multiple inputs with the same ID, but different types, is a thing someone would do for some reason?

I don't think it's intended for the rate policy to depend on the input type, so I'm fairly certain that this.inputRatePolicies was always meant to be using inputId (i.e., name) rather than both the name and the type.

Already reviewed...also Joe has stepped in to provide a review