Model binding support for fields

This commit adds support to the `ModelBinding` code for binding fields, not just properties, in models. This allows the POD types for a project to look like:
```
public class Employee
{
  public int EmployeeID;
  public string Name;
  public string PhoneNumber;
  public decimal Salary;
}
```
There is a good reason to write POD types this way, rather than using implicit property implementations. The last paragraph below explains it, though it is not strictly pertinent to this pull request.

This commit includes full unit testing of this change, including all of the necessary changes to existing tests.

Implicit property implementations create backing fields that include `<` and `>` characters, in order to ensure that you cannot, in your own C# code, ever create another member with the same name. This, in turn, causes performance issues if `DataContractSerializer` is used on the same type. `DataContractSerializer` works like a traditional serializer, enumerating the *private* members of the type. It then tries to create XML elements named after these members. If the members contain `<` and `>` characters, an `XmlException` is produced. This exception can be seen by running code in a debugger set to break on all thrown exceptions, even if they're handled. The `DataContractSerializer` code is aware of this problem and handles the exception internally by doing additional escaping on the member name, but by then the performance hit of the exception has already been incurred. The only ways to avoid this exception are to either expand out the property definitions so that you control the name of the backing field, or to not use properties at all, and the latter solution is much more concise and has no downsides when the type really is just a POD type.
@albertjan, @khellang, do you have a recommendation for a naming convention that encompasses both properties and fields without being so generic as "member"? I did consider that when I was writing the code, but nothing obvious came to bind, and I ended up just thinking of a "binding property" as being a "property or field that is readable & writeable".