ExtUtils::ParseXS: use fields.pm and doc fields

Add 'use fields' to make the fields of a ExtUtils::ParseXS object be
fixed and enforced.

Background:

ExtUtils::ParseXS is the guts of what used to be a standalone script,
xsubpp, which used to use many package variables.

When this code was split out into ExtUtils::ParseXS, some of those
package variables became lexical variables, while others became
members of the ExtUtils::ParseXS object (i.e. keys within the object
hash).

Due to Perl's liassez-faire attitude towards what can go inside an object
hash, and the general lack of organisation within this sprawling mess
of code, the object eventually accumulated 77 field members, many
undocumented, and certainly with no central point of documentation.

This commit adds 'use fields' and 'my ExtUtils::ParseXS $self' to this
module and its children. These together make use of an underappreciated
perl feature which allows you to create hashes with a fixed set of keys
(via 'use fields') and where the use of incorrect keys can often be
detected at compile-time (via 'my Type $self; $self->{bad_literal_key}').

Adding 'use fields' then allowed me to chase down all the keys used
by the object hash. I then documented them all.

This allowed me to detect a bug (to be fixed shortly): XsubAlias is a
typo intending to be XsubAliases; and to spot things like the fact that
there are three fields called:

    interface
    interfaces
    Interfaces

Which could probably be better named.

The next few commits will do a bunch of renaming and rationalisation of
these object fields.

Note that due to a build-time circularity, this commit actually does a
conditional 'require fields; fields->import(...)' rather than 'use
fields', as fields depends on Hash::Util which is an XS module, which
depends on us. So while perl is being freshly built, the object fields
are not initially enforced, but are later on.

In terms of user-visible changes, if code which uses this module
naughtily tries to add extra keys to the object hash, they'll now get an
error, and they'll have to properly subclass the object instead.

Author: iabyn