docs: Add 'What this library can't test' section

[kalpeshsingh]

This PR is regarding #574 issue.

This will help newbies developers to understand the purpose of the library and what is not expected out of it.
This will help developers to understand guiding principles better.

[nickserv]

Technically these things can be tested, but only indirectly (unlike Enzyme, testing library doesn't provide APIs for accessing them directly). Maybe we could word it so it's more about avoiding testing internals by not supporting APIs like that, similar to what's in the docs but a bit simpler and easier to learn at a glance. I still think these are three good topics though.

[kalpeshsingh]

Sounds fair and reasonable, @nickmccurdy.
Here is re-worded version.

What you should avoid with Testing Library

Testing Library encourage you to avoid testing internals of the component (though you can test them). The Guiding Principles of this library emphasize on tests that closely resemble how your web pages are interacted by the users.

You may want to avoid following internals for testing -

1. Internal state of the component
2. Internal methods
3. Lifecycle methods of the component
4. Child component

---

If this adds value to developers then I can update PR.

[kentcdodds]

I'm ok with including something like this, but not on this page. DOM Testing Library doesn't really have anything to do with components directly. That's a framework-specific thing.

[alexkrolick]

Feel free to reuse this content from an old article I wrote: https://medium.com/@alexkrolick/what-makes-a-good-test-dff3df6058a2#0843

[kalpeshsingh]

@kentcdodds - This will be right below What this library is not section on Introduction page.
Attaching marked screenshot.

[kentcdodds]

Ah, yeah, that makes sense 👍

[kentcdodds]

I made a few minor modifications. Thanks!

[kentcdodds]

@all-contributors please add @kalpeshsingh for docs

[allcontributors]

@kentcdodds

I've put up a pull request to add @kalpeshsingh! 🎉