Methods can be invoked on non-mapster supported/initialized elements

[techfg]

Describe the bug ImageMapster currently has sporadic behavior when invoking a method on an element. For example:

1. Methods can be called on elements that are not yet been initialized - In some cases, the method returns without error (e.g. select) and in some cases there is an error (e.g., keys) but the error is not meaningful (e.g. Uncaught Can't access data until binding complete.).
2. Methods can be called on unsupported elements (e.g. div)

To Reproduce Steps to reproduce the behavior:

1. Open tooltips example
2. Execute $('.navmenu').mapster('select') in console
3. Method completes successfully even though div is not a valid target and mapster cannot be applied to it
4. Execute $('.navmenu').mapster('keys') in console
5. Method encounters Uncaught Can't access data until binding complete. exception even though div is not a valid target and mapster cannot be applied to it.
6. Add the following HTML to the example page

    <img
      id="testimage"
      src="images/beatles_basic.jpg"
      usemap="#beatles-map"
    />

7. Execute $('#testimage').mapster('select')
8. Method completes successfully even though mapster is not initialized
9. Execute $('#testimage').mapster('keys') in console
10. Method encounters Uncaught Can't access data until binding complete. which is misleading because mapster is not even initialized

Expected behavior Mapster should only support img/area elements, track initialization and provide meaningful error messages based on situation. Additionally, mapster creates internal elements and there is code in-place that "ignore" these elements during method execution - this additional processing overhead can be avoided by ensuring that mapster is only called on "valid" (user created img/area & initialized) elements.

Screenshots N/A

Desktop (please complete the following information): N/A

Smartphone (please complete the following information): N/A

Additional context While technically a bug, fixing this properly would result in a breaking change for existing code that uses IM that doesn't follow standard jQuery usage guidelines (wrt to selectors) so it should be saved for next major release and marked as a breaking change.