Simplify pull request template

[turbaszek]

Remove the checklist of always checked points. It seems that the checklist is redundant because it creates more confusion than good. So this PR proposes a new templated which:

1. Focuses on description - if no comment is present in commit then there will be
   ^ Add meaningful description above
   Which I hope will be a call to action for authors.

2. Reduces the amount of information that a new contributor has to digest. We just kindly remind about tests coverage and docs. The code quality will be verified by CI checks.

Additionally, we have the welcome bot that will provide more additional resources.

The template looks like this from Github PR editor:

<!--
Thank you for contributing! Please make sure that your code changes
are covered with tests. And in case of new features or big changes
remember to adjust the documentation.

Feel free to ping committers for the review!

In case of existing issue, reference it using one of the following:

closes: #ISSUE
related: #ISSUE
-->

---
**^ Add meaningful description above**

Read the **[Pull Request Guidelines](https://github.com/apache/airflow/blob/master/CONTRIBUTING.rst#pull-request-guidelines)** for more information.
In case of fundamental code change, Airflow Improvement Proposal ([AIP](https://cwiki.apache.org/confluence/display/AIRFLOW/Airflow+Improvements+Proposals)) is needed.
In case of a new dependency, check compliance with the [ASF 3rd Party License Policy](https://www.apache.org/legal/resolved.html#category-x).
In case of backwards incompatible changes please leave a note in [UPDATING.md](https://github.com/apache/airflow/blob/master/UPDATING.md).

How this work in real life? If there's no comment in commit then the **Add meaningful ... line will be first. If there's a comment the line can be easily removed and I don't think this will cause any trouble. We can even make the boring cyborg remove it in case of description.

---

Make sure to mark the boxes below before creating PR: [x]

• Description above provides context of the change
• Unit tests coverage for changes (not needed for documentation changes)
• Target Github ISSUE in description if exists
• Commits follow "How to write a good git commit message"
• Relevant documentation is updated including usage instructions.
• I will engage committers as explained in Contribution Workflow Example.

---

In case of fundamental code change, Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in UPDATING.md.
Read the Pull Request Guidelines for more information.

[turbaszek]

Summoning @apache/airflow-committers

[potiuk]

I like this much better than the checklist one. I agree it becomes very quickly an unnecessary boilerplate.

The one problem I have with the "Here is the meaningful description of my changes." the way it is written is that I often provide meaningful description in the commit itself and then it will land above the line. Which I do not really like.

So maybe we should adopt the commonly used pattern (and a nice call to action I think as well):

---
^ Add meaningful description above 

I think this is also nice that there is only one area (above the first ---) that you should edit as PR author.

[kaxil]

I feel somewhere we should add a link to Commits follow "How to write a good git commit message"

Maybe even in comments or in Pull Request Guidelines too is fine :)

[turbaszek]

I've added the link to the comment. It's also available in CONTRIBUTING.rst:

-   Adhere to guidelines for commit messages described in this `article <http://chris.beams.io/posts/git-commit/>`__.
    This makes the lives of those who come after you a lot easier.

[kaxil]

Let's remove

airflow/.github/mergeable.yml

Lines 38 to 43 in 3064811

	- do: description
	must_exclude:
	regex: \[ \]
	message: There are incomplete TODO task(s) unchecked.
	no_empty:
	enabled: true

too

[zhongjiajie]

Maybe someone change the comment directly, in this case can't target to issue, how could we avoid it?

[turbaszek]

The description can always be updated so there should be no problem. Also we as committers should pay attention to link PR with issues so the auto-close feature works