- Don't support par or war since par is not a standard format and outputting to
  war doesn't make sense.
- Add boilerplate manifest when outputting to Jar.
- Remove "XXX check conversion" comments because I don't care.
- Add a test.

Refactor the way output is handled in CommandLineInterface -- now it will be stored in-memory until all code generators have completed, then dumped to disk all at once.  While this means that protoc uses more memory, the code is much simpler, and handles insertions much faster.  Also, this made it easier to implement a useful feature:  insertions will be indented to match the insertion point line.  Therefore, when inserting into Python code, you don't have to figure out how much to indent your inserted code.  The refactoring should also make it easier to implement output-to-jar at some point.

Actually, that last revision can be simpler -- we don't need to parse strings at all, as simply entering 1e1000 as a float literal in Python will be evaluated as infinity.

In Python, avoid relying on float('inf') and float('nan') as these don't work on Windows with Python pre-2.6.

In Java's TextFormat, correcty concatenate adjacent string literals, as C++ does.  Also fix a bug in handling of single-quoted strings.

Make extension identifiers final.  This improves security when untrusted code is present in the same class loader.  In order to get around initialization ordering issues, I simply made the constructor for extension identifiers take no arguments and deferred initialization to an internalInit() method, which generated code will always call during init.

getExtension() on an empty repeated field should return an empty list, not a singular default value.

When serializing to an ostream, verify that there were no stream-level errors before returning success.

Clarify that pushLimit() does not limit the number of bytes CodedInputStream will read from the underlying InputStream.

Ensure that 'once' objects are declared using the macro.  This is either the third or fourth time I've screwed this up when down-integrating, because our internal code does not require the macro (it's not portable) and on Linux a pthread_once_t that is zero-initialized just happens to work.  So, I only discover the problem when I test on Mac, then kick myself for making the same mistake yet again.  No more!  This time, I have renamed GoogleOnceType to ProtobufOnceType, thus making the type name differ from our internal code.  As a result, if you don't update the decls to use the macros, they won't compile.  Hah!  Take that, future self!