Add way to change bar programmatically without triggering listeners

[narfman0]

Currently the easiest way to change without triggering a listener is something like:

bottomBar.setOnTabSelectListener(null);
bottomBar.selectTabAtPosition(position, true);
bottomBar.setOnTabSelectListener(this, false);

This changeset exposes a way to avoid triggering listeners through the most likely call the user is already making. Previous API should behave the same, only users invoking this with triggerListeners (false) explicitly will see the difference.

Note: updateSelectedTab basically just calls listeners and updates currentTabPositon. I would have added triggerListeners there too, but it seems to be more like a setCurrentTabAndFireEvents :) so why nto just set current tab.

Fixes #499

[coveralls]

Coverage increased (+0.07%) to 57.244% when pulling d004792 on narfman0:master into 338ee86 on roughike:master.

[yombunker]

@narfman0 too many booleans already, in my opinion even one can sometimes result in ambiguous meaning.

[coveralls]

Coverage increased (+0.03%) to 66.469% when pulling b96f6cc on narfman0:master into c7e0fb5 on roughike:master.

[yombunker]

Find a different way of doing this, there are too many booleans, and you could easily do the same on your side, set a boolean and when the callback comes back you ignore it and reset the boolean.

[narfman0]

You want another method, like selectTabAtPositionDontTriggerListeners? Not great method name :) but that kind of thing?

You suggest adding a boolean, managing my own state, and taking different logic based on internals of the bottom bar library that now I have to know about. All that over an overloaded method with an added boolean. Why would clients want this? Clunky, unclear, design I don't want in my app(s). You saw #499 ? Currently as I said, having a helper function clear/reset the listeners before/after updating is the cleanest way for me.

"too many booleans": Booleans are concise. triggerListeners doesn't sound ambiguous, though I would like more optimal suggestions. Assuming you just mean in a method signature e.g. trigger(false, false) I could see wondering the 1st vs 2nd false seeing it for the first time... for 3 seconds before hovering/single keystroke go to definition away from finding the name. By default, I'd expect clients to use the shorter methods, and not find this unless they need it when selecting tabs programmatically. Java is a verbose language; adding another method with more overloaded/specific/tailored functionality is expected and typical. :)