Fix determinism of itersubclasses in Python 3.4; see https://github.com/astropy/astropy/pull/1969

git-svn-id: http://svn6.assembla.com/svn/pyfits/trunk@2481 ed100bfc-0583-0410-97f2-c26b58777a21
Initial stub for the schema implementation with the simplest, most useless test case passing :)
Progress on schemas that actually do something: First a modicum of validation for schema definitions, though there's more to be done on that front.  Next, implementation of the first schema property: mandatory.
Initial support for position validation
Revert to allowing schemas for individual keywords to be defined as class attributes on the schema.  The syntax is just too convenient, and will work for the vast majority of standard FITS keywords (keywords containing a hyphen being the notable exception).  For the corner cases, it is still possible to provide an *additional* class attribute called keywords that is a dict mapping FITS keywords (as strings) to their definitions.
Initial implementation of value validation.  I feel some aspects of this might be weird or confusing and that it will likely see some rework in the future.  But this is useful as a starting point.
Moved forward some on validation of schemas against the metaschema
Initial support for composition of schemas via Python's normal class inheritance
Some further tweaks for multiple inheritance to work properly; this requires more copying than I'm happy with, but it's not very important for now.
In Python, bool is a subclass of int. But we want strict distinction between int and bool types, so ensure that a value validator that specifies int or bool type is *strict* in that respect.
Fixed issue where the name of the schema class was not being passed through to the meta-schema validation methods for use in raising schema definition errors.  This might change again, however, once switching over to a system that allows all definition errors to be collected, rather than raising an exception the first time one is encountered
Add initial support for 'indexed' keywords--that is sets of keywords that have some index as part of the keyword--the most famous example being the NAXISn keywords.  This is implemented in such a way that NAXISn can be interpolated into NAXIS1, NAXIS2, ..., NAXISn where n is the value of the NAXIS keyword.  I'm still not sure I'm completely happy with how this is implemented in the schema definition, and I have gone through many iterations of this scheme.  But this works for now--it can certainly be reworked based on whatever feedback this garners.
Refactored this code a bit so that it's hopefully a little more understandable.
Simplified somewhat the type checking by using some pre-defined tuples of types.
Add support for passing the current index (or indices) of an indexed keyword through to all the validate methods.  Adds yet more complexity but is necessary and useful for certain use cases.  Added support for returning required position from a function.
Initial support for the 'valid' keyword property.  In some ways this is the opposite of 'mandatory', and only has any effect when its value is set to False (otherwise the keyword is 'valid' in that header).
Partially implemented schema for the basic HDU types defined by the FITS standard.  Some keywords are not properly validated yet, and there are no schema yet for non-standard extensions (namely Compressed image HDUs).  Added a test to see if all the test files validate against their schemas (excluding compressed images for now).  One HDU in zerowidth.fits in fact did contain invalid keywords for a binary table (BSCALE, BZERO, and BUNIT none of which make sense for a binary table) so I updated that file.  Will be interesting to see how many other non-conforming files are out there....
FITS standard date validation
Updated position keyword property so that if it is given as a callable, in addition to returning an explicit position as an int it can also return a True/False boolean value stating whether the keyword is in the correct position (regardless of what that position may be)
Added a test and fix for a subtle bug I discovered in inheritance of keyword properties from base classes.  It is necessary to keep track on each schema a list of keywords that were *explicitly* defiend properties on that schema, rather than keywords that were inherited from base classes.  This plays a big role in determining which keyword properties should take precedence when walking the MRO.