Refactoring and optimization by decorators

[xmedeko]

@dtcooper @pR0Ps
I would like to start discussion about general change of the FitFile architecture, already started in #61 and #57. The problem is speed, code simplicity vs. feature richness.

IMO is may be solved by the decorator pattern, e.g. see this example on python.org. (It's not exactly same as Python decorators, but the Python decorators may be used to implement that.) I think the main method is FitFile.get_messages() which should yield message by message. The other decorators has to implements get_messages() and may add further functionality.

Example: MessageCacheDecorator. I have proposed in #61 to remove message caching from the FitFile. Then a new class MessageCacheDecorator may be created. So, users, which would like to keep the old functionality would do just:

fit = FitFile(...)
fit = MessageCacheDecorator(fit)
m1 = fit.get_messages(...)
m2 = fit.messages

Similarly to the data processors. Each conversion may be a decorator, too. So, it does not need to be in the FitFile core. And, if you really need to keep BC, the FitFile may be split to: FitFileDecoder and FitFile just as a decorator (or subclass) to FitFileDecoder.