Disambiguate classnames

[jcheng5]

Change the class of the plot_ly object (built but not widgetized)
to plotly_hash, and simplify print/knit_print methods. This fixes
compatibility issues with RStudio's upcoming R Notebook feature.

@cpsievert You may be wondering why I didn't change the classname
of the as.widget output instead of the plotly_build output; it's because
htmlwidgets uses the first element of the classname to look up the
filename of the htmlwidget binding (htmlwidgets/plotly.js), so it would've
been a more invasive change to go that way.

cc @jjallaire

[jcheng5]

BTW, I was not able to figure out how to successfully run tests locally. Running the first code block here gave me:

Error in normalizePath("../../plotly-test-table", mustWork = T) :
  path[1]="../../plotly-test-table": No such file or directory

[cpsievert]

Thanks! Sorry for the confusing wrt testing. Did you try building the comparison table (i.e., did you set Sys.setenv('PLOTLY_TABLE' = 'TRUE') before running tests)? If you want to build the comparison table, you also need to clone https://github.com/cpsievert/plotly-test-table (I'll add a not about that), but I'd recommend running tests with Sys.setenv('PLOTLY_TABLE' = 'FALSE') for now as I'm still sorting out issues.

This fixes compatibility issues with RStudio's upcoming R Notebook feature.

Just a wild guess, is it generally a bad idea to export knit_print.PKGNAME in a package named PKGNAME?

[jcheng5]

It wasn't knit_print.PKGNAME that was the problem, it was that you reached into the htmlwidgets namespace for the method implementation (but could not have done otherwise given the ambiguous class name). The R Notebook feature provides a different implementation for print.htmlwidget and knit_print.htmlwidget, in a different package.

[cpsievert]

Ah, ok. Also FYI the travis failures are false positives (due to a credential issue on my end). I'll add you as a collaborator so any future pull requests can more smoothly

[cpsievert]

ack, I'm still not familiar with pushing to pull requests from a foreign remote, so closing this in favor of #562