Remove separate infection pathways for vaccination groups

[pratikunterwegs]

This PR makes changes to how vaccine groups are modelled in {daedalus}. The model trades explicit tracking of infection pathways of different vaccine groups for a gain in performance. There are some performance gains, but some country-pathogen-vaccine strategy combinations still result in a stiff system which slows down model runs.

1. Vaccine groups now share a single infection pathway, cutting the number of model compartments to 539 (49 age and economic groups $\times$ 11 epi and data compartments) from 1323. This improves performance in most cases by about 3x.

2. The state variable adds two compartments, one for vaccinated individuals who have a lower susceptibility to infection ($\tau \beta$; $\tau = 0.5$), and one for the number of new vaccinations per timestep.

3. Individuals in both susceptible and recovered compartments are considered eligible for vaccination. Vaccinated individuals transition at the rate $\psi$ into the susceptible compartment, but not into the recovered compartment. The vaccine-derived protection and waning dynamics need more work to ensure they have realistic transition rates, and/or to make transition rates independent and flexible.

4. The helper functions values_to_state(), r_eff(), get_hospitalisations(), make_initial_state(), prepare_output(), and get_daily_vaccinations() have been updated to reflect the reduced state size.

5. Tests have been updated to reflect reduced state size.

6. Reduced use of {rlang} for environment access and modification.

Tagging @patcatgit and @robj411 as well - I still can't find/confirm Kanchan - what is her GH id? Happy to tweak this implementation per feedback.

[richfitz]

This sort of major bookkeeping change is always hard to review - it's interesting how little effect it has on the tests though, which really suggests that even if these might be needed in the future, the extra detail is not important for the model atm. Will leave this for the science side to comment on the epi implications of the change

[richfitz]

Curious about dropping rlang for this here - I know we discussed using it in the first place. FWIW, I think the base way of doing this is fine, and was never very sure about what we were getting from rlang for this particular use (it's got lots of good functions in the package, just not clear about this one really)

[pratikunterwegs]

Looking into the profiling, the environment access/assignment functions seemed to be the next most time-consuming functions. Since they're not essential, I thought I'd remove them. I've retained {rlang} in places where it's not doing any harm, e.g. in parameter preparation.