Rationalize the existence of FinancialSeries

[milktrader]

The scope of this package has shrunk now that we can piggyback off TimeSeries for most time series methods.

There is the metadata types that are useful, but otherwise the only substantial code is possibly the TickData type. FinancialTimeSeries is simply an alias for a TimeArray with a specific meta field.

There needs to be more to the story than some simple definitions, because that could easily live in FinancialBlotter.

[milktrader]

The R FinancialInstrument package is the closest analog to a possible role for FinancialSeries. It defines its goal as

Construct, manage and store contract specifications for trading

[milktrader]

Perhaps change the name (and objectives ostensibly) to FinancialAssets

Keep track of contract specifications for the ES future expiring in December, for example.

The question is where to define FinancialTimeSeries and maybe even if it needs to be defined here. There is also some build up with working with tick data and designing the TickData type. The difference here with TimeSeries TimeArray is that there are often duplicate timestamps. Can this be solved by adding a smaller time increment?

[milktrader]

One thing that makes this package different from R's FinancialInstrument may be the fact that user-defined types could be defined here. It's not clear to me what sort of objects FinancialInstrument creates, but I would venture to guess that Julia's type system will be more flexible to handle the requirements.