Make multiple @ThriftMethods with the same name easier to diagnose/fix
Make all @ThriftStruct classes final

Also:
- makes generator generate final classes.
- adds a check that all thrift struct classes used as parameters, return types, or field types are final

The motivation is to reduce confusion about what level of support swift has for inheritance: you can build your thrift struct types by inheriting from base types that have some common thrift fields, but you should not try to declare a base type for a param, return value, or field, and then try to send derived types in place of that base type (because thrift protocol doesn't support polymorphism).
Generate boxed types for optional fields

Swift handles thrift "optional" fields by leaving them null when they
are not read, and not writing them when they are null. This is not
compatible with primitive types, so for "optional" fields, the generator
should produce boxed types.
Change parser ThriftField field name to "requiredness"

The parser object representing a ThriftField had the name "required", but the allowed values of this field are "REQUIRED", "OPTIONAL", and "NONE" so calling the field "required" is a bit confusing.

This is only a parser change and shouldn't have any effect on external swift-codec or swift-service APIs.
Change field in ThriftField annotation from "required" to "requiredness"

I'm going to transform this from a boolean to an enum specifying whether the field has optional, required, or default behavior, so, similar to the parser change, "required" no longer makes sense as a field name.
Make formatting of metadata errors/warnings more consistent
Make it an error to specify multiple types for a different appearances of a single thrift field
[swift-generator] generate values for 'requiredness' field of ThriftField annotation
[swift2thrift-generator] generate 'optional' or 'required' modifiers based on swift-codec field metadata
Use 'requiredness' data on ThriftField annotations when building metadata for the field
Make it an error to have multiple extracted or multiple specified names for a single field

The existing code was trying to allow for the cases that some appearances of the field might have been explicitly renamed in a @ThriftField annotation, while others may not have been, so there could be conflicts between the set of names retreived by getOrExtractThriftFieldName(). For this reason, conflicting names was only a warning.

However it should be an error to have multiple explicit names, or multiple implicit names. This change checks each separately to make sure everything is consistent.
Revert "Make it an error to have multiple extracted or multiple specified names for a single field"

This reverts commit fec043189859fef6628dabfa12c688e62a1ad58e.

There are problems with this change in that I thought "extractName()" always gets the implicit name (not the name in the annotation) but this is not true for ParameterInjections, where the annotation name takes precedence. This is fixable but I'm not sure it's worth it at this time, so I'll revert this diff, making it a warning again to have multiple names for a thrift field.
Make it possible to configure worker executor by name

This change allows you to bind ExecutorServices to names, and then select a named executor from the set that was bound using a string property in ThriftServerConfig (thus allowing you to configure the possible exeuctors in your custom Guice module, and then select one by name in your application's config map).