Merge DatedOISRateHelper with OISRateHelper

[eltoder]

Add a second constructor overload to OISRateHelper which works like
DatedOISRateHelper. Deprecate DatedOISRateHelper.

This removes a lot of code duplication and also adds support for custom
pillar dates to DatedOISRateHelper's equivalent.

[coveralls]

coverage: 72.786% (+0.002%) from 72.784%
when pulling 458f24b on eltoder:feature/dated-ois-custom-pillar
into 5ee8f89 on lballabio:master.

[lballabio]

Thanks! Is this compatible with #1912, or a subset of it, or alternative?

Also, it seems to me that the duplication (or the additional template base class) are there because we wanted to inherit OISRateHelper and DatedOISRateHelper from RelativeDateRateHelper and RateHelper, respectively, and that's just so that the relative-date helper can inherit 4 or 5 lines of code. What if we folded DatedOISRateHelper into OISRateHelper instead? It could be a single OISRateHelper class with two different constructors. It could inherit from RateHelper and copy a bit of missing behavior from RelativeDateRateHelper. If this works, we could consider doing away with RelativeDateRateHelper altogether. What do you think?

[eltoder]

This is a subset of #1912 with a more self-contained and possibly slightly simpler implementation. The same approach can be used to add DatedSwapRateHelper as an alternative to #1912.

I don't think we need to copy-paste code from RelativeDateRateHelper, but what to do depends on what end state we want to have. If we want "relative" and "dated" helpers as separate classes, we can use the approach in this PR (a common base class template parametrized by its base class) or the approach from #1912 (a common base class which is not a template, but make RelativeDateRateHelper a template so it can be added on top of any base class). I think the latter is a bit better.

If we want "relative" and "dated" helpers to be different constructors in the same class, we can simply add a bool to RelativeDateRateHelper's constructor. I think this will just work, and it avoids the need for the common base class, so the code will be simpler. That said, I think this approach has a few downsides:

1. OISRateHelper and DatedOISRateHelper have a lot of constructor arguments. In Python we use kwargs to pass only a few of them and have a much more readable syntax. Unfortunately, SWIG does not support kwargs on overloaded methods. Removing kwargs is also a breaking change for the existing code. So we will likely have to keep separate classes at least in SWIG for Python.
2. We'll also have to keep DatedOISRateHelper in C++ for backwards compatibility at least for some time.
3. This will make DatedOISRateHelper a bit less efficient (it does not need to store the arguments), but that's probably OK.

[eltoder]

For the two classes solution another option is to use virtual base class and multiple inheritance instead of templates. I'm not sure if this is more easily understood and it has some run-time overhead.

[lballabio]

I'd try going for one class; it's the same instrument, having two classes was an accident of the implementation.

Drawback 1 can be addressed in the SWIG layer: instead of exporting the dated constructor directly, we can export it via a createDated static method we can add from SWIG. This way we have both constructors usable with kwargs. For drawback 2 we use the usual deprecation machinery. I wouldn't worry about 3.

[eltoder]

@lballabio I merged DatedOISRateHelper with OISRateHelper and deprecated the former as discussed. Please take a look.

[lballabio]

I've pushed a few very minor changes but it looks good to me, thanks a lot.

[lballabio]

We can add DatedSwapRateHelper in the same way.