extend Return.convert with optional startType and periodicity functionality

`Return.convert` originally written by @erolbicero uses `xts` properties to detect the return calculation type of an input series and convert it to a different type.

`Return.convert` is also somewhat of an incomplete function and is not exported by `PerformanceAnalytics`, so we should make it more robust and then export it.

Not all time series of returns will contain the return type in the xts metadata. We should stop if there is no metadata and inform the user of the situation. In order to allow for the conversion of "unmarked" returns series by adding a `startType` field that takes the same arguments as `destinationType` which would define the return type we are converting "from".

Additionally, it would be nice for a "conversion" utility to have the ability to "convert" a time series to a lower periodicity, as it is often convenient to take e.g. intraday or daily data and convert it to lower periodicity (e.g. intraday to hourly or daily, daily to weekly or monthly, etc.)

## Implementation notes (possibly non-exhaustive):

for the implementation of `startType`:
- add a default `destinationType` of 'NULL' to the existing list, in case the user just wants to lower the periodicity
- add stop/warning if the input series has no return type metadata, and suggest `startType`
- add `startType` argument to the function signature, with the same `c(NULL, 'discrete','log','difference', 'level')` options
- add stop/warn if `startType` is provided and the input series has a different return type in its metadata
- use the optional `startType` for conversion

for the implementation of periodicity:
- add dots to the function signature, and make sure they are passed appropriately to lower level functions as needed
- add `period` and `k` arguments to the function signature with a default `period=NULL` and `k=1` (as with xts function `to.period`)
- check the `periodicity` of the input data
- stop/warn if the periodicity of the input data is higher than the periodicity requested in `to_period`
- if type conversion is also happening, do the type conversion *before* changing the periodicity
- use `endpoints` to determine the indexes of the k'th periods
- aggregate cumulative returns of the correct type by using `period.apply` over the endpoints
- handle multicolumn data which may have leading or trailing NA's

Additionally, we should create, document, and export a `to.period.returns` wrapper for `Return.convert` that aligns with the structure of xts's `to.period` to allow for easier user experience for users familiar with `to.period`. The wrapper should call `Rturn.convert` and provide additional arguments like `name` not included in `Return.convert`. (obviously the `OHLC` argument of `to.period` doesn't make sense for `to.period.returns`)

overall implementation requirements:
- add use of `checkData` to convert to `xts` internally
- add use of `reclass` to convert back to the input type if `xts` data was not provided
- fully document all the new options and behaviors
- add `@examples` to the documentation (and example snapshot update to the example tests)
- add a full set of `testthat` tests to the test suite, verifying both coverage and *correctness* of the type and periodicity conversions
- `@export` the functions