Do not override font-lock for case/continue/break labels

This prevents us from displaying words following "case", "continue",
and "break" in unexpected faces inside comments.

Signed-off-by: Eric James Michael Ritz <lobbyjones@gmail.com>
Do not highling function calls or variables within comments

This addresses the same issue as commit 4a7a6b0b.  We often use
regular expressions to capture parts of code and apply syntax
highlighting to those captured groups via font-lock definitions like
this:

    (1 font-lock-variable-name-face t t)

That third parameter causes a problem.  That controls the ‘override’
properties meaning, in this case, that Emacs will apply the face
font-lock-variable-name-face to whatever we capture even if it already
has syntax highlighting.  It overrides existing faces.  That behavior
causes comments like

    // $foo->bar

to have syntax highlighting for ‘bar’ like any other variable.  We can
fix this by changing the override parameter to ‘keep’, which tells
font-lock to keep any existing face.  Or to put it another way, to
only apply the face if none is already there.  This fixes the issue
with comments since they are highlighting before we try to
highlighting variables, function calls, et cetera.
Update php-mode-modified for today’s syntax and font-lock changes
Add Nate Eagleson to the list of contributors

Whoops.  I was in a rush yesterday and forgot to do this after putting
his recent patch into the master branch.  My apologies.
Add a shell script to run all tests from the command-line

This script is also meant for use with ‘git bisect run’ to help
developers track down regressions.
Mention using run-tests.sh with ‘git bisect run’ in the README
Merge branch 'test-shell-script'

* test-shell-script:
  Mention using run-tests.sh with ‘git bisect run’ in the README
  Add a shell script to run all tests from the command-line
Remove mention of better heredoc formatting from the README

Commit f910f9e9 reverts a series of buggy patches related to improving
heredoc support.  However, the README still incorrectly claims to have
that improvement.
Begin process of migrating font-lock and indentation to `cc-mode`

It looks like most of the font-lock support can be done through creative use of
`c-lang-defconst`. I am using the following files for moral guidance:

- [`yang-mode`](http://www.emacswiki.org/emacs/yang-mode.el)
- [`protobuf-mode`](http://code.google.com/p/protobuf/source/browse/trunk/editors/protobuf-mode.el)
- [`vala-mode`](https://live.gnome.org/Vala/Emacs?action=AttachFile&do=get&target=vala-mode.el)
- [`derived-mode-ex`](http://cc-mode.sourceforge.net/derived-mode-ex.el)
- [`actionscript-mode-connors`](http://www.emacswiki.org/emacs/actionscript-mode-connors.el)
- [`cuda-mode`](http://www.emacswiki.org/emacs/CudaMode)
- [`cc-php-js-cs`](http://www.mail-archive.com/gnu-emacs-sources@gnu.org/msg01804/cc-php-js-cs.el)
- [`boogie-mode`](http://www.pm.inf.ethz.ch/people/josephr/boogie-mode)
Finish first pass of cc-mode definitions.

Right now, there is redundancy with other font-locking functions.
Basic functionality, with errors.

Font-locking works but there are the following errors

- Errors when attempting to indent

- Redundantly display a menu for "C" and "PHP". The PHP menu has additional
  functions, but includes the content of the "C" menu. `java-mode` does not have
  this problem and seems to be set up in the same way.

- I do not have much confidence that the variables are correctly defined. This
  will need a lot more work.
Don't set `*-suffix-key` variables to `nil`

This causes indentation to error.