feat: support 'editable' prop on TextInput

[pplytas]

Summary

Prevent fireEvent from calling event handlers on TextInput when editable prop is false.
Fixes #476

Implementation:
Added isTextInputComponent() helper function to check if element is a TextInput and if it is then check editable prop instead of onStartShouldSetResponder

Test plan

Added tests for standalone TextInput and TextInput with a nested Text component.

[DallasCarraher]

nit pick but wouldn't this work here too return element?.type === TextInput

[DallasCarraher]

also, I like your first proposal. I'm not sure if proposal 2 is necessary but I'll wait to hear what someone else has to say.

[thymikee]

Let's go with 1 for now, we do something similar in src/helpers/getByAPI.js

[pplytas]

Thanks for the catch @DallasCarraher!
Went with the 1st approach as suggested.
6cbc3c07a509f1c0f0754e83129e81a30268a87

[DallasCarraher]

Sorry maybe I'm naïve or missing something here so I apologize if this is a silly question, but what is this testing? The editable prop isn't being spread / drilled down in your TextInputWrapper so it shouldn't affect the nested TextInput anyway right?

[pplytas]

Hm I added this test since we have a similar one for TouchableOpacity above it, but it seems like it is not necessary in the case of TextInput where we don't care about the event propagating to the custom parent component. I'll remove it thanks!

5f861da352b569c124db17b3f93c5e63dd0ccf77

[thymikee]

please revert this check. host components are always of string type

[pplytas]

74b8c8a28e8957324404b77615288060fc34f9fc

[thymikee]

There's no need for this test, can we remove it?

[pplytas]

Just to clarify, this test is also mentioned in #517 (comment).
Should we keep it therefore or remove it?

[thymikee]

we could add the custom TextInputWrapper here and combine all cases into a single test :)

[mdjastrzebski]

LGTM :-)

@pitpitpat thank you for your work!

[pplytas]

Squashed the fixups. Ready to go!