Issue warning when reading from and writing to the same measurement and retention policy

Writing data back to the same measurement and retention policy that the data was initially read from will cause a strange looping cycle that can have unintended side effects.

For example, the TICK script:

```
stream
|from().measurement('system')
|eval(lambda: "n_cpus" + 1).as('n_cpus')
|InfluxDBOut().database('telegraf').measurement('system')
```

When using Telegraf's `system` measurement, will infinitely increment the `n_cpus` field until the task is stopped. `n_cpus` should be `8`, but when using the task above:

```
> select n_cpus from system where time > now() - 30m limit 10
name: system
------------
time n_cpus
2016-08-26T17:00:30.165861723Z 188
2016-08-26T17:00:40.167731931Z 186
2016-08-26T17:00:50.168388752Z 185
2016-08-26T17:01:00.093640763Z 185
2016-08-26T17:01:10.167517378Z 183
2016-08-26T17:01:20.168493088Z 182
2016-08-26T17:01:30.170129495Z 180
2016-08-26T17:01:40.163970708Z 180
2016-08-26T17:01:50.166989363Z 179
2016-08-26T17:02:00.092814428Z 177
```

The documentation should be updated to include a warning, and a message should be issued to the logs when a task reads from and writes to the same database/measurement/retention policy (when possible).

/cc @nathanielc

Start with the TICK script using from().measurement('system') and InfluxDBOut().measurement('system') to reproduce the self-reading and self-writing loop. Review how tasks emit log messages and where the related documentation is maintained; done means documenting the warning and issuing a log message when the database, measurement, and retention policy match where possible.

Written by the indexing model from the issue text.