Guards for record types

[jackfirth]

Part of #42. Record types should allow guards. The signature of a record guard should match the contract (-> record-type? (-> any/c ... any)), accepting information about the record type (for error reporting purposes) and the proposed value for each field of the record. It should return one actual value to use for each field. The acceptance of the record type information and the individual fields should be separated by a partial application barrier in order to allow first-order checks on the record type (such as those used by record-guard/c, described below) without incurring check penalties on each instance construction. The fields should be processed in keyword-sorted order, in the same manner that keyword-apply and make-keyword-procedure handle keywords.

Then, the make-record-implementation function and the define-record-type macro should both accept a #:guard parameter containing a function matching the record guard contract. In order to prevent users from having to deal with field order directly, a (record-guard/c #:<kw> contract ...) contract combinator should statically sort the contracts by field keyword and construct the guard procedure. It should also use the record-type? supplied to the guard to check that the keywords given to record-guard/c match up exactly with the field names in the record type.