Undesirable results from select_tradeperiod() about pinkfish HOT 1 CLOSED

I have implemented a less aggressive nan strategy that fixes the problem described in this issue. This approach gives more control and responsibility to the pinkfish user to solve problems with their timeseries, while also providing options to automatically fix problems.

(1) fetch_timeseries() no longer removes rows with nan values.
(2) select_tradeperiod() lets you specify the columns to check for nan values via check_fields argument. The default is ['close']. You can specify an empty list if you want.
(3) finalize_timeseries() has an argument that lets you specify whether to drop rows with nan values via dropna, default is False.
(4) The stock_market_calendar is no longer applied unless force_stock_market_calendar=True is set in select_tradeperiod().

A warning is issued if nan values are detected within finalize_timeseries(). A function was added find_nan_rows()' to help track down problematic timeseries. The above changes were also made for portfolio, except dropna` default is True in portfolio.finalize_timeseries().

With the default settings, the example above works as you expect.

"Yahoo data downloads from 1971 ... not good enough, but adequate for a quick test."
This is or was a problem on Windows platform only. You can see if it's been resolved by setting from_year=1900 in fetch_timeseries(). If it's no longer a problem, please let me know and I'll remove the check.

from pinkfish.