Common settings for fastmath, sharrow_skip, and other compute controls across components

[jpn--]

The reason why the school escort model was failing with sharrow relates to the fastmath setting.

Part of how sharrow accelerates code evaluation is by turning on the "fastmath" compiler optimizations in Numba. Using this setting has numerous effects, but two are salient here:

1. It makes the code run faster
2. It can cause elementary operations to give unexpected results where one or more operands is NaN, e.g. normally evaluating x < 0 should result in False when x is NaN but with fastmath turned on the result might be True instead; the actual result of such an operation is not defined and might be hardware dependent.

We do not want to simply turn off fastmath, as the speed we get from (1) is desirable and the problems created by (2) don't actually occur in most models, as most data columns in our tables don't include missing values. But the school escort model DOES include missing values (e.g. the age of the 3rd child in a household with less than 3 children).

This PR introduces a sharrow_fastmath setting for all relevant components, with True as the default for nearly all Sharrow-compiled model components, but adds a mechanism to turn it off for individual components as needed. The school escort model has the default for this setting changed to False.

[dhensle]

Just wanted to make sure you knew that the string removal work was performed already here: ActivitySim/activitysim-prototype-mtc#4

[dhensle]

There are a number of submodels which do not include this setting, e.g. destination models, scheduling, transit pass subsidy, etc. Those also need to be passed with the fastmath argument, especially since their yaml files will now accept the setting since the BaseLogitComponentSettings was updated.

[jpn--]

@dhensle you make a good point. Also, while I'm pushing fastmath through all the components, I realized its convenient to wrap all component level sharrow controls together (i.e., also skip) to ensure a consistent user interface.

[jpn--]

@dhensle this PR is ready for your re-review. I believe I addressed your concerns, and then some.

[jpn--]

In thinking about the solution for #842, I realized we probably want these controls to be more general that "sharrow_settings", something more like "compute_settings". The reason we are seeing the overflow in #842 seems to be because we are using bottleneck for the computations, but if we activate compute.use_numexpr instead the problem goes away. If we make these controls more general, we can trigger this pandas setting here as well. This allows us to change compute settings in a consistent component-specific manner for non-sharrow compute. For now, that includes settings the pandas options compute.use_bottleneck, compute.use_numexpr, and compute.use_numba (see pandas.set_option).

[jpn--]

@dhensle Will you have time to finish a (re)review of this PR this morning so we can merge it? It is now blocking progress on #833 as we want to coordinate the settings.

[dhensle]

I think you just missed the transit_pass_subsidy model. Other than that I think it looks good.