Carefully parse warning messages when building documentation

[mik-laj]

When the sphinx returns a warning that the script cannot process properly, an exception is raised

For example:

/opt/airflow/docs/howto/use-user-defined-exec-context.rst: WARNING: document isn't included in any toctree

Results in the following exception

Traceback (most recent call last):
  File "/opt/airflow/docs/build", line 288, in <module>
    build_sphinx_docs()
  File "/opt/airflow/docs/build", line 270, in build_sphinx_docs
    sphinx_build_errors = parse_sphinx_warnings(warning_text)
  File "/opt/airflow/docs/build", line 233, in parse_sphinx_warnings
    file_path=warning_parts[0], line_no=int(warning_parts[1]), message=warning_parts[2]
ValueError: invalid literal for int() with base 10: ' WARNING'

After this change, problems with warning processing do not result in an exception, but a raw message is displayed.

Related slack discussion: https://apache-airflow.slack.com/archives/C012FP2T9NW/p1588515270029000

---

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.

[kaxil]

Can you add a description to the PR with before and After or why this is needed

[mik-laj]

@kaxil I updated the description