restructured tooltipster and added elementTooltip
elementTooltip : accounted for the case when icon is activated
merging the destroy method fix onto this branch
The update method is now immediate. Had to isolate the update process from the check interval. The tooltip will not react anymore to a content change made without calling the update method, at least for now.
Fixed unbinding on body to unbind only the plugin handlers
Removed all .data calls except the attachment of the plugin to the original element, replaced by instance variables. Removed confusing  variable names and used the self name convention. Removed useless var repetitions. Removed the awkward getContent function (to be replaced later).
Unbind only the right functions for touch devices. Tooltips could previously collide with each other or even with the rest of the page before I namespaced
Removed the weird, unexpected, slow and almost undocumented feature that allowed to interact with the tooltips inside a container
Changed the order of things in the library : things which are basically bindings on the window all go to the end
Bind on orientationchange anyway, it cannot hurt and touchDevice is not accurate anyway
Fixed the way content is provided to the plugin to accept content in any form, especially an object with bindings etc. It is not tooltipster's job to filter stuff in the content and try to prevent XSS: people should not allow everything in their title attribute in the first place. Besides, the existing getContent function caused issues and not working adequately either
Added the tooltipstered class to put the window events back in order
Removed the lines that made changes in a select input close the tooltip if interactiveAutoClose is true. The plugin should not dictate an arbitrary behavior of some content of the tooltip, users should instead bind their content as they wish to the desired public methods.
Forgot to bypass the .data method for window events
Added an exception to warn when a method is called on an unitialized element
Fixed the window events which did not work if the plugin name was different from tooltipster
Reviewed some comments that needed to be changed + a couple details
The default value for the onlyOne option is now false. A tooltip initialized with this value to true currently closes tooltips even if they have been set to interactive and not autoclosable. As the plugin is getting more robust and ready for heavy interactions, this behavior is questionable and should at least be disabled by default. Most people will not see the difference anyway since tooltips are closed quickly by default.
In showTooltip, find and hide the opened tooltips using the new tooltipstered class and the regular public method
Updated copyrights to MIT licence