More feature types

Currently used type system has not enough feature types.

Feature type is the stuff which tells us how to process that feature. More precisely, how we should preprocess it and what kinds of models are useful to fit against it.

So let's have more feature types:

• {"type":"cyclic", "period": [60, 60, 24, 7]} (period is an array, each element defines a period in counts of previous periods) - anything having some useful to the domain cyclic structure. Enables circle transform.
• "survival" - means that survival analysis methods should be applied to the column, if it is target. Otherwise treat as a simple numerical.
• {"type":"time", "base":0} - means that it is absolute time. Inherits from cyclic.
• "calendartime" - enables feature engineering using calendar features like holidays, festivals, other periodical events dates like Olimpics, Football cup, annual conferences dates, TV schedules, etc...
• "location" - enables feature engineering tied to information from maps, like big circle distances, distances to city centre, city, state, distances to POIs of different types, etc
• "NLP" - enables NLP feature engineering, like words embeddings and LSTM encoders
• "mysteryString" - enables automatic feature extraction from strings which are not natural languages

the ways how exactly the features are processed are implementation defined.

No files, tests, or entry points are named. Start by locating the existing feature type system, then clarify how the proposed cyclic, survival, time, calendartime, location, NLP, and mysteryString types should be represented and processed; done requires an agreed implementation scope.