Add timestamps to Exported CSV

[yuce]

Overview

• Adds support for adding timestamps to exported CSVs. The timestamps are found by transforming appropriate view names. Appropriate view name == views that correspond to the time quantum of the field.
• Adds timestamps=ENABLE flag to /export endpoint. If ENABLE is true then the timestamps are included in the CSV. Otherwise they are excluded.
• timestamps=false returns only the bits from viewStandard and timestamps=true returns only the bits from the appropriate time views. So, in order to get all bits, the user should call /export twice with timestamps=true (to get bits with timestamps) and timestamps=false (to get bits without timestamps).

Example:

$ curl localhost:10101/index/i1 -d ''
$ curl localhost:10101/index/i1/field/f1 -d '{"options":{"type":"time","timeQuantum":"YMDH"}}'
$ curl localhost:10101/index/i1/query -d 'Set(10, f1=1, 2019-04-01T12:34)'
$ curl localhost:10101/index/i1/query -d 'Set(10, f1=1, 2019-03-01T12:34)'
$ curl localhost:10101/index/i1/query -d 'Set(100, f1=1)'
$ curl -H "Accept: text/csv" "localhost:10101/export?index=i1&field=f1&shard=0&timestamps=false"
1,10
1,100
$ curl -H "Accept: text/csv" "localhost:10101/export?index=i1&field=f1&shard=0&timestamps=true"
1,10,2019-03-01T12:00
1,10,2019-04-01T12:00

Pull request checklist

• [ ] I have read the contributing guide.
• [ ] I have agreed to the Contributor License Agreement.
• [ ] I have updated the documentation.
• [ ] I have resolved any merge conflicts.
• [ ] I have included tests that cover my changes.
• [ ] All new and existing tests pass.
• [ ] Make sure PR title conforms to convention in CHANGELOG.md.
• [ ] Add appropriate changelog label to PR (if applicable).

Code review checklist

This is the checklist that the reviewer will follow while reviewing your pull request. You do not need to do anything with this checklist, but be aware of what the reviewer will be looking for.

• [ ] Ensure that any changes to external docs have been included in this pull request.
• [ ] If the changes require that minor/major versions need to be updated, tag the PR appropriately.
• [ ] Ensure the new code is properly commented and follows Idiomatic Go.
• [ ] Check that tests have been written and that they cover the new functionality.
• [ ] Run tests and ensure they pass.
• [ ] Build and run the code, performing any applicable integration testing.
• [ ] Make sure PR title conforms to convention in CHANGELOG.md.
• [ ] Make sure PR is tagged with appropriate changelog label.

[yuce]

This should be good to review.