update checkpatch.pl to version 0.07

This version brings a number of new checks, fixes for flase
positives, plus a clarification of the output to better guide use.  Of
note:

  - checks for documentation for new __setup calls
  - clearer reporting where braces and parenthesis are involved
  - reports for closing brace and semi-colon spacing
  - reports on unwanted externs

This patch includes an update to the documentation on checkpatch.pl
itself to clarify when it should be used and to indicate that it
is not intended as the final arbitor of style.

Full changelog:

Andy Whitcroft (19):
      Version: 0.07
      ensure we do not apply control brace checks to preprocesor directives
      add {u,s}{8,16,32,64} to the type matcher
      accept lack of spacing after the semicolons in for (;;)
      report new externs in .c files
      fix up typedef exclusion for function prototypes
      else trailing statements check need to account for \ at end of line
      add enums to the type matcher
      add missing check descriptions
      suppress double reporting of ** spacing
      report on do{ spacing issues
      include an example of the brace/parenthesis in output
      check for spacing after closing braces
      prevent double reports on pointer spacing issues
      handle blank continuation lines on macros
      classify all reports error, warning, or check
      revamp hanging { checks and apply in context
      no spaces after the last ; in a for is ok
      check __setup has a corresponding addition to documentation

David Woodhouse (1):
      limit character set used in patches and descriptions to UTF-8
Signed-off-by: NAndy Whitcroft <apw@shadowen.org>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: "Randy.Dunlap" <rdunlap@xenotime.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Documentation/SubmittingPatches

@@ -464,9 +464,25 @@ section Linus Computer Science 101.
 Nuff said.  If your code deviates too much from this, it is likely
 to be rejected without further review, and without comment.
 
+Once significant exception is when moving code from one file to
+another in this case you should not modify the moved code at all in
+the same patch which moves it.  This clearly delineates the act of
+moving the code and your changes.  This greatly aids review of the
+actual differences and allows tools to better track the history of
+the code itself.
+
 Check your patches with the patch style checker prior to submission
-(scripts/checkpatch.pl).  You should be able to justify all
-violations that remain in your patch.
+(scripts/checkpatch.pl).  The style checker should be viewed as
+a guide not as the final word.  If your code looks better with
+a violation then its probably best left alone.
+
+The checker reports at three levels:
+ - ERROR: things that are very likely to be wrong
+ - WARNING: things requiring careful review
+ - CHECK: things requiring thought
+
+You should be able to justify all violations that remain in your
+patch.