Add CachingBackend, address performance of JDBCBackend.item_get_elements

[khaeru]

This PR:

• Refactors JDBCBackend.item_get_elements() to not use pd.DataFrame.from_dict(), which can be slow. Instead, an empty pd.DataFrame is allocated and values from the Java side are copied into it.
• Re-adds [:] slice syntax when accessing arrays via JPype. This was added in 2017 (554c9be) but removed in Add Backend, JDBCBackend, Model, GAMSModel classes #182. It is significantly faster than accessing the object without the slice; see Fast conversion from Java byte array to Numpy uint8 array jpype-project/jpype#71. Although that issue is closed, this workaround still seems necessary. It is not discussed in the JPype documentation. This PR also adds a comment clearly stating this is necessary. Incorporates WIP: Convert java arrays to Series on fetching model elements #214.
• Moves caching out of ixmp.core and into a CachingBackend class. Other backends can inherit from this class and use its caching features; or just inherit from the base Backend.

In the longer run, we will need to add performance tests (e.g. using pytest-benchmark) to ensure that the ixmp test suite directly tests that ixmp has satisfactory performance for data on the scale of MESSAGE-GLOBIOM (~10 dimensions, ~10⁶ rows). That will be a separate issue.

How to review

• Read the code!
• Try to load large parameters and ensure that performance is better when the cache is hit.
  • Import the code and use a custom script to load some large MESSAGE-GLOBIOM parameters.
  • Change N_dim in test_report_size to 8 and run only that test with pytest -k report_size.

PR checklist

• Tests added.
• Documentation added.
• Release notes updated.

[khaeru]

@OFR-IIASA notes that this change brings the time to load the land_out MESSAGE-GLOBIOM parameter down from 470 seconds to 50 seconds, which is “reasonable”. This variable has about 1.9 million rows, so the benchmark is roughly 26 µs/row.

He also reports that the caching appears to work.

[OFR-IIASA]

Code looks fine; I ran the tests and additional tests of my own to check that the speed of retrieving data as well as caching works as desired - all OK.

[zikolach]

Looks good to me. Would be great to compare memory allocation after switching to categorical dtypes. Thanks @khaeru!