Added option to fire change event to be compatible with default behavior

[nathanjosiah]

This allows the default change event to be fired at the appropriate times. As it stands now, the plugin breaks default behavior and makes it very difficult to integrate into applications. For example, the ifChanged event fires multiple times both before and after the actual change has happened with no way to differentiate between the two and the ifClicked event doesn't fire when keyboard shortcuts are used. Even if these events are to be used they require everyone in a codebase to know them and can remember to use the propriatary methods and event names. This PR makes all of this a non-issue by enabling default behavior with events and event naming.
Since you didn't have a contributors file, I wasn't sure what to do about versioning as well as your prefered minifier so I ran it through Closure Compiler and left the version numbers all the same (1.0.2)

This PR would address #244

Let me know of any feedback including if you would like me to include examples, update README with new options, or change version numbers.

[nathanjosiah]

I have updated version numbers and added documentation to the new option. Probably worth mentioning, the new option from this PR is false by default to maintain the current behavior by default for backwards compatibility.

[nathanjosiah]

I have added another commit that allows the element to be manipulated without using iCheck and triggering the change event will update the state of the plugin elements.

[nathanjosiah]

Here is an demo of all of the changed from this PR.

[drgullin]

This can be easily done by changing nearly a list line in code:

input[_callback]('ifChanged')[_callback]('if' + capitalize(callback))[_callback]('change');

[drgullin]

@nathanjosiah thanks, this is supported now by default in v1.0.3.