Improved multistrata parameter UX and ADRIO support

[JavadocMD]

A typical multistrata modeling setup might define population for each its strata like this:

MyMultistrataRume().build(
  ...
  params={
    ...,
    "*::*::population_by_age_table": acs5.PopulationByAgeTable(),
    "gpm:young::*::population": acs5.PopulationByAge(0, 19),
    "gpm:mid::*::population": acs5.PopulationByAge(20, 59),
    "gpm:old::*::population": acs5.PopulationByAge(60, 79),
  },
)

A few friction points:

• This is fairly verbose, and gets worse as the number of strata increase.
• It's fertile ground for typo and copy-paste mistakes.
• PopulationByAgeTable is sort of a hack to avoid fetching the same ACS5 data repeatedly. This just adds to the user's burden unnecessarily.
• As we increase the ways you can slice population data, the number of ADRIO classes also balloons. This makes the ACS5 module harder to learn and use properly.

If parameters and ADRIOs could be made aware of the multistrata RUME environment, if they treated strata as another shape axis, we could simplify the interface to something like this:

MyMultistrataRume().build(
  ...
  params={
    ...,
    "*::*::population": acs5.Population().by_age(
      [(0, 19), (20, 59), (60,)]  # age ranges as a list of tuples, or maybe varargs
    ),
  },
)

This also adopts builder-style chained method syntax to collapse related ADRIOs into a single class, which is more powerful when stratifying on more than one characteristic such as age and race.

acs5.Population()
  .by_age([(0, 19), (20, 59), (60,)])
  .by_race([
    "White Alone",
    "Black or African American Alone",
    Combine("Asian Alone", "Native Hawaiian and Other Pacific Islander Alone"),
    ALL_REMAINING,
  ])

ACS5 defines the race categories available; in this example we envision the need to select some as-is, select others in combination (summed), and select all other remaining (not explicitly-selected) categories and combining those.

There are a number of ADRIOs which could benefit from similar treatment.

Additionally, we should include functions to make it easier to adapt common formats of in-memory and file data for use as a multistrata parameter: DataFrames, CSV files, etc.

[JavadocMD]

Alternative syntax accepting dicts to explicitly name strata:

acs5.Population()
  .by_age({
     "young": (0, 19),
     "adult": (20, 59),
     "older": (60,),
  })
  .by_race({
    "white": "White Alone",
    "black": "Black or African American Alone",
    "aanhpi": Combine("Asian Alone", "Native Hawaiian and Other Pacific Islander Alone"),
    "other": ALL_REMAINING,
  })

Without names, strata associations fall back to definition order. For this ADRIO, the implied ordering (how would have to define the strata in order for them to line up as intended) would be:

1. young_white
2. young_black
3. young_aanhpi
4. young_other
5. adult_white
6. adult_black
7. adult_aanhpi
8. adult_other
9. older_white
10. older_black
11. older_aanhpi
12. older_other

In other words, strata characteristics included earlier change "slower" (young, young, young, young, ...) and later change "faster" (white, black, aanhpi, other, ...). This is analogous to writing a set of nested for loops with age being the outer loop and race being the inner loop.

It will be allowed to swap the order of the method calls to change the iteration order; i.e., calling acs5.Population().by_race(...).by_age(...) would be:

1. white_young
2. white_adult
3. white_older
4. black_young
5. (and so on)

Of course specifying just acs5.Population() will load non-stratified totals.