CONTRIBUTE.md: mention tests done on pull requests

request](https://github.com/curl/curl/pulls) to the curl project to have

changes merged.

We prefer pull requests to mailed patches, as it makes it a proper git commit

that is easy to merge and they are easy to track and not that easy to loose

in the flood of many emails, like they sometimes do on the mailing lists.

We strongly prefer pull requests to mailed patches, as it makes it a proper

git commit that is easy to merge and they are easy to track and not that easy

to loose in the flood of many emails, like they sometimes do on the mailing

lists.

Every pull request submitted will automatically be tested in several different

ways. Every pull request is verfied that:

 - ... the code still builds, warning-free, on Linux and macOS, with both

   clang and gcc

 - ... the code still builds fine on Windows with several MSVC versions

 - ... the code still builds with cmake on Linux, with gcc and clang

 - ... the code follows rudimentary code style rules

 - ... the test suite still runs 100% fine

 - ... the release tarball (the "dist") still works

 - ... the code coverage doesn't shrink drastically

If the pull-request fails one of these tests, it will show up as a red X and

you are expected to fix the problem. If you don't understand whan the issue is

or have other problems to fix the complaint, just ask and other project

members will likely be able to help out.

When you adjust your pull requests after review, consider squashing the

commits so that we can review the full updated version more easily.

Make the patch against as recent source versions as possible.

If you've followed the tips in this document and your patch still hasn't been

incorporated or responded to after some weeks, consider resubmitting it to

the list or better yet: change it to a pull request.

incorporated or responded to after some weeks, consider resubmitting it to the

list or better yet: change it to a pull request.

### Write good commit messages