get_smry_stats() behaviour on uneven end-date.

[berland]

fmu.ensemble 1.0 ensured an ensemble-wide common timegrid for get_smry_stats(), but in 2.0, this is no longer so, realizations can end at any time, and get_smry(time_index='monthly') is not guaranteed to give the same ending month for every realization.

This is fine for ensemble plotting, but for statistics it is not so easy.

get_smry_stats() has two choices when dealing with uneven end-dates:

• Ignore it, and let pandas handle it through groupby('DATE'). This gives a discontinuity in the mean at dates where a realization stops to exist.
• Ensure a common end-date, and extrapolate rates as zeros, and cumulatives as constants.

If the realization has crashed unintentionally (Eclipse bug etc.) both of these are wrong, and the user must solve the problem by filtering out the entire failed realization.

Since real failures should be filtered out, get_smry_stats() may assume that the premature end-date of a realization is intentional from the user, and then the correct way to handle it is to extrapolate rates as zero etc. Correct extrapolation is provided by libecl, which means that either get_smry_stats() must call get_smry() once more with an end-date set, or extrapolate using ad-hoc pandas code (using metadata to find cumulatives/rates).