Clarify implications of field of view overlaps on starfish processing

[ambrosejcarr]

Starfish does not currently over-sample images, which means that there are edge effects that are introduced by filtering and segmentation that may not be recoverable unless users provide images with adequate overlaps.

This is not currently communicated well in our documentation. We should decide whether we want to support non-overlapping data by loading fields of view that are adjacent to the target field of view, or to request users submit fields of view that have overlaps, and then to support that in all algorithms.

In the short term, the existing limitations of starfish should be clearly documented.

Ref slack conversation: https://spacetx.slack.com/archives/CAR91U354/p1553107970076100

[berl]

starfish is currently agnostic to overlap between FOVs.
Our format and FOV-centric processing allows for FOVs whose physical coordinates are not overlapping or even touching. Shouldn't this be easier to deal with than the case of overlapping FOVs? Any mechanism to deal with overlapping FOVs should be able to treat zero overlap as a special case.