README: Reflect the project's actual methods

When I wrote the README before, I was basically demanding the use of
Git's signed-off messages, which is just wrong-headed. Also change the
example commit so it uses an action stamp, no more hard dependency on
a sha1 identifier that may change if the repository is rewritten (has
happened) or moved to another VCS (has happened, also); additionally,
it's just a better example commit to use. :-)

Remove the "Build system" section which encouraged a "Do Not Touch"
philosophy which is also wrong-headed. Any change for improvement is
self-evident: should not tell people to not bother without explaining
themselves.

Also, rename the file so GitHub renders it nicely.

README.asc

@@ -109,12 +109,6 @@ It is sensible to also heed the following guidelines:
     means no imps, cyberdemons, etc).  The new monsters will behave the
     same way as the originals, but will be totally new.
 
-=== Build process
-
-The Freedoom build process is fairly complete and should not change
-without good reason.  Write a decent explanation why your method is
-better; just enough to get your point across is good enough.
-
 === Documentation
 
 Freedoom always needs help with the documentation, so please send your
@@ -138,18 +132,14 @@ patches, but keep in mind:
 TODO: Figure out the best method of doing this.  This mainly requires
 time to see what works best.
 
-If you use git, make sure your commit messages start with a single line,
-under 72 characters, which provides an adequate summary of your changes.
-You should prefix this line with the component you are committing (for
-example, ``map17: fixed unbeatable map'').  This should be followed by a
-blank line and a paragraph or more to explain your change in detail (for
-example, explaining what part of the map was broken).  See commit
-49dc6ca861d4b85ca16b219941ecb86d3e172ac1 for an example.  Sign your
-comments with +git commit -s+, these leaves a trail of whose hands a
-commit went through and could be useful for some purposes; git alone can
-give an indication of up to two people, however the AUTHOR/COMMITTER
-fields are not quite reliable or flexible enough for the same
-information.
+If you use git, make sure your commit messages start with a single
+line, under 72 characters, which provides an adequate summary of your
+changes. You should prefix this line with the component you are commit
+(for example, ``map17: fixed unbeatable map''). This should be
+followed by a blank line and more explanation if it's needed (for
+example, explaining what part of the map was broken). The commit
+2013-12-20T16:06:55Z!rjy@users.sourceforge.net shows a good example of
+a well-structured commit message.
 
 You should commit often; each important change should get its own
 commit, but minor changes need not.  Take advantage of git's ability to