Move profile_line() out of viewer

The profile_line() function is actually quite useful outside of the viewer and interactive LineProfiler plugin. I've moved it to the `measure` package and imported it from there for use in the plugin.

In addition, I fixed an apparent bug in its functionality: it appeared to return the profile in the wrong direction:

before:
```python
In [1]: x = array([[2, 2, 2, 1, 1, 1]])

In [2]: y = vstack([zeros_like(x), x, x, x, zeros_like(x)])

In [3]: y
Out[3]: 
array([[0, 0, 0, 0, 0, 0],
       [2, 2, 2, 1, 1, 1],
       [2, 2, 2, 1, 1, 1],
       [2, 2, 2, 1, 1, 1],
       [0, 0, 0, 0, 0, 0]])

In [4]: from skimage import measure as m

In [5]: m.profile_line(y, ((1, 2), (5, 2)))
Out[5]: 
array([[ 1.],
       [ 1.],
       [ 2.],
       [ 2.]])
```

after:
```
In [15]: m.profile_line(y, ((1, 2), (5, 2)))
Out[15]: 
array([[ 2.],
       [ 2.],
       [ 1.],
       [ 1.]])
```

It also adds a `mode` parameter to be passed in to the `ndimage.map_coordinates` interpolation routine to estimate values outside the image.

In addition, I'd like to request people's opinion about two additional proposed changes.

1) Currently, the API uses x and y as inputs, meaning the horizontal and vertical dimensions, meaning columns and rows, meaning exactly the opposite of typical numpy indexing. Since we use numpy indexing almost everywhere else, would people support changing this to expect numpy-style coordinates? Since it is not currently a public function, I think we could change this without worrying about API changes. In which case, I would actually support the syntax `profile_line(img, src_point, dst_point)`, where each of those is a valid numpy indexing tuple into `img`.

2) I would also change the return type to be a 1D array when input is a 2D, single channel image, and 2D array when input is a 2D + c image.

Thoughts? @tonysyu, @JDWarner?