Create a first draft of the Starfish API + CLI

[ambrosejcarr]

Before we introduce the spaceTx community to starfish, we should attempt to standardize a coherent API that is consistent with the CLI.

Currently, there are many methods that should be private that are exposed, which makes the API confusing.

• pipeline components all have different execution methods (filter, segment, run, ...). These should be unified into one method (run, maybe?)
• many methods that are currently public should be made private, including several methods on the base classes
• object imports in __init__.py should be made clearer, and since we want to move towards an import pattern where we import the pipeline component, we should make all the implementing components private.

[ambrosejcarr]

Proposal for the starfish API:

- starfish
  - Experiment
  - ImageStack
  - IntensityTable
  - Codebook
  - image: 
    - filter
      - <filters>
    - register
      - FourierShift
    - segment
      - Watershed
  - spots
    - detect
      - GaussianBlobLog
      - LocalMaxPeakFinder
      - ConnectedComponent
    - decode
      - MetricDistance
      - PerRoundMax
    - assign
      - PointInPolygon

Questions:

1. Do we want a pipeline directory?
2. I moved assign into features since it relates to assigning features. Does that make sense to others?
3. We could take this a step further and separate out the image related tasks into an image directory, similar to how we have a features directory. image would subsume filter, register and segment.
4. I'm still conflicted about spots/pixels. I feel like ConnectedComponent is a better name for a pixel-based spot finder, but I'm unsure whether we should split up the pixel spot finder per @dganguli 's suggestion on a recent PR. I think Deep is correct that the logical progression is PixelsToFeatures -> MetricDistance -> ConnectedComponents, however in this strategy ConnectedComponents doesn't fit with the interface that a spot detector uses, which is ImageStack -> IntensityTable. I would be happier leaving it stuck together for now, and breaking it apart when we identify a use case that requires that modularity.

@dganguli @ttung @berl @freeman-lab

[ambrosejcarr]

Closed by #405