Drop latest NumPy supported version to 1.18

[bonjourmauko]

Fixes #1009
Supersedes #1012
Depended on by #1010

Bug fix

• Drop latest NumPy supported version to 1.18.x
  • OpenFisca relies on MyPy for optional duck & static type checking
  • When libraries do not implement their own types, MyPy provides stubs, or type sheds
  • Thanks to __future__.annotations, those stubs or type sheds are casted to typing.Any
  • Since 1.20.x, NumPy now provides their own type definitions
  • The introduction of NumPy 1.20.x in Upgrade numpy to add support for M1 processors #990 caused one major problem:
    • It is general practice to do not import at runtime modules only used for typing purposes, thanks to the typing.TYPE_CHEKING variable
    • The new numpy.typing module was being imported at runtime, rendering OpenFisca unusable to all users depending on previous versions of NumPy (1.20.x-)
  • These changes revert Upgrade numpy to add support for M1 processors #990 and solve OpenFisca-Core seems to depend on numpy 1.20  #1009 and Fix numpy version constraints #1012

[sandcha]

Compared to #990 content and all seems to be reverted.

I see that this PR isn't the method that we chose with @benjello and @guillett (!= method 2️⃣ on slack) but it was before you analyzed was we did in the past for a similar situation and I agree that this way is cleaner (and doesn't introduce a new way of managing unpublished revisions with its risks).

[bonjourmauko]

Thanks a lot @sandcha !

I see that this PR isn't the method that we chose with @benjello and @guillett (!= method 2️⃣ on slack) but it was before you analysed was we did in the past for a similar situation and I agree that this way is cleaner (and doesn't introduce a new way of managing unpublished revisions with its risks).

Again thanks a lot for your proactiveness to try to find a way to unblock users 😃

There are a couple of factors that convinced me to propose this way of dealing with the issue, and here instead of Slack:

1. As you mention, it seems that we already have a way of dealing with this situation, but its documentation is largely absent. In general, I think that the whole corpus of previous decisions is an asset we have to take into account —referring to the "jurisprudence" more often and calling "referendums" only in case of dissent as a subsidiary decision-making strategy.

2. In parallel, I feel the boundary between Github's and Slack's role is rather blurry. This proposal is thus motivated by the following hypothetical rule-of-thumb:

• OpenFisca's Slack is an éphémère space for mingling, exchange, cross-pollination, etc. Being éphémère renders it IMHO unsuitable for documenting decisions —hence not "opposable".

• OpenFisca's Slack is also underrepresented when it comes to the core, most of the public discussions (23% of total) being held in the context of the country models. Thus I'm not even sure it is a suitable place for product decision-making.

• Regarding that previous point: what works for example with France, where we can today with confidence have in a same call a decent amount of contributor's representation, the same does not hold yet true for the core.

3. Finally I think the fact that we already lack a clear process for maintenance/contribution (Have a clear process for maintenance/contribution #1004) makes it the much more undesirable to further increase information and participation asymmetry: how to weight my opinion, yours, @guillett's, @benjello's, etc., expressed over a semi-public space, in a thread, regarding the whole of the core's users' and contributors' in the context of a decision that will likely impact them all? —it is at least here more a question of transparency than legitimacy, otherwise I wouldn't be writing this comment myself.

This issue is rather easy because of 1. supra —I cheated! 🤣— but others won't be so.