Making filtering text inputs easy / simple again

[pbodnar]

This is de-facto a revert of the pull request "#54 from
abolishme/patch-1" (see the discussion there) and follow-up commits, while also clarifying how the
original code was possibly meant and bringing back some "reasonable defaults".

Plus fixing related (structure) typos in the README file.

[pbodnar]

Note that the I have left the filterContentEditable option untouched, so as firstly, not to remove all the recent work done and secondly, I am not quite sure if to filter even these types of elements by setting the seemingly universal-enough filterTextInputs option. Letting this decision to others for now...

Note 2: In the very original forked repository, one can see that these input elements were always filtered: select, textarea, input with apropriate type attribute and elements with the contenteditable attribute (and this behavior was not even switchable by an option).

[rpocklin]

I think we need some tests here. The reason the option exists is because some users have asked for it (for better or worse).

[pbodnar]

OK, so is this project completely abandoned by the maintainers? The latest commits and documentation I tried to fix with this PR, together with wrong tagging (see 58038e6#diff-5736fc95626e37d54f44e395ad7aea8120507f84525485498a7d909db88a9e72) left this project in a very messy state, IMO. It looks like maintaining another fork is the only way to go now?

[rpocklin]

I'll be reviewing this and the previous PR over the next few days to consider this PR and possibly release a new version of the library.

[rpocklin]

@pbodnar can you please take a look at #63 which should do the minimum required to revert the behaviour whilst leaving the configuration customisable (and with your improvements to the docs)?

[pbodnar]

@rpocklin, thank you, I've left the feedback at the new PR. I hope you still have time? Anyway, I guess you can close this PR then.