compute_flux() now accepts Kelvin brightness temperature units

I have added support for Kelvin main beam brightness temperature units in ```astrodendro.flux.compute_flux()```. While previous discussions have noted (e.g., #54, #57) that it may be better to provide a function to convert Kelvin datacubes to less ambiguous units before performing analysis computations, my use-case is better served by doing the computations directly on Kelvin data (rather than transforming my datacubes to Jy/beam before running the catalog analysis) - for example, I'd like my dendrograms to remain in Kelvins rather than be converted to Jy/beam. As @astrofrog noted in an email from 1 Feb 2014, astropy now has a "brightness temperature" equivalency between K and Jy/beam, so this pull request uses this equivalency. 

I have included a "warning"-style print statement in the code, so that "Warning: 'Kelvin' units interpreted as main beam brightness temperature." is printed each time this computation runs. I have also updated the docs to reflect the ability to use Kelvin units. Finally, I included a new test case in ```test_compute_flux``` that uses `K` units with the appropriate metadata.

This code should pass Travis tests, but I'll address any failures if they come up.

Note that this addition sidesteps the still-relevant issue raised in #107, which is concerned with renaming "compute_flux" to "compute_flux_density" and ensuring that spectral line datacubes are treated properly when summed over a frequency or velocity axis.
No, it was the first question (didn't realize that `1.33 = 2pi/8ln2`). I think I messed up the numerator/denominator (my equation is pixels per beam, not beams per pixel). 

In any event, I think it would be clearer if you use `omega_beam` in your definitition of `beams_per_pixel`