Allow indexing in ParameterScales

[nikhilwoodruff]

ParameterScales are really useful features, but there is a use case that as far as I know they don't currently support: brackets which differ by a category. For example, taxes in the US use different thresholds by filing status (single, joint, separate, etc.). We'd rather not duplicate the rates, so it'd be great if we could do the following:

scale.calc(income, filer_status_enum_array) -> [values]

where the parameter looks like this:

brackets:
  - rate:
      2019-01-01: 0.2
    threshold:
      SINGLE:
        2019-01-01: 10_000
      JOINT:
        2019-01-01: 20_000

Happy to implement (I think it'd be simple enough, and would be backwards compatible). @benjello are there any use-cases for this in other countries do you think?

[benjello]

@nikhilwoodruff : Yes go ahead ! It won't break the current situation and there should be use case in the french legislation.

Might be worth exploring te use of an interface like:

scale[filer_status_enum_array].calc(income) -> [values]

@clallemand @pzuldp @Sasha-Laniece : i am thinking of some cotisation depending on size of company or number of persons with handicap employed etc.

[nikhilwoodruff]

Thanks @benjello - I like that example interface, will go with that. Just one possible issue though with your example of a tax scale differing by an integer (if I understand correctly), rather than a string (like the US filer status): scales currently use integer keys to select brackets, so there'd be a conflict there (should scale[1] return the second bracket, or the scale for companies of size 1?). I'm thinking I'll just leave this for now and implement for string/enum indices, but if there's a workaround you can think of that'd be helpful? Thanks

[benjello]

@nikhilwoodruff : I get your point. Go ahead. Usually there are categories of size so we could deal with that.
But if we need more general scale casting, we may have to revamp the actual structure.

cc @MattiSG @maukoquiroga @sandcha @eraviart

[nikhilwoodruff]

Update on this: started, got probably a third of the way but I got swamped by the complexity a bit, my implementation needs a re-think. Will get around to it eventually.