Profile include support

[ghudson@MIT.EDU]

We previously decided to add include-file support to the profile
library (see
http://mailman.mit.edu/pipermail/krbdev/2010-July/009170.html).  I've
done a project writeup a working proof-of-concept implementation
(currently private; I'll just check it into the trunk when I'm done).
The project writeup is at:

  http://k5wiki.kerberos.org/wiki/Projects/Profile_Includes

This project is under review until Friday of this week (2010-08-27).
For convenience of review, here is the contents of the "Open Issues"
section:

* glob() may not exist on all systems. Does it exist on Windows? If it
  does not exist, what fallback position should the code take? Options
  are:
  - Fail to compile if glob() does not exist.
  - Disable include support if glob() does not exist.
  - Allow only includes of explicit filenames if glob() does not
    exist.
  - Provide a glob() implementation if it does not exist. This may be
    a substantial amount of code.

* The syntax "include PATTERN" is simple and clear, but may not be
  optimal. It could break existing profile files which contain an
  "initial comment" (any text before the first line beginning with
  '[') with a line which happens to begin with "include". Also, adding
  an include directive anywhere other than the beginning of a
  krb5.conf file would cause earlier versions of krb5 to generate a
  syntax error. Other syntax options include:
  - Masquerade as a comment: #include PATTERN
  - Masquerade as a section: [include PATTERN]
  - Distinctive punctuation: @include PATTERN

* Nothing in the design prevents include directives containing
  relative paths or patterns. Such an include directive would have
  unpredictable effects since the current working directory would be
  different for different invocations of the krb5 library. Should the
  profile library protect the administrator by restricting include
  directives to absolute paths? If so, how should it portably
  recognize an absolute path?

* Should an include directive ever result in a fatal error? Possible
  error cases include:
  - Including an explicit filename (not a pattern) which does not
    exist.
  - Including a pattern which has no matches. Note that it is
    impossible to distinguish this case from the previous one without
    breaking the abstraction barrier of glob().
  - Including a pattern or filename which attempts to descend into
    directories which the process has no permission to read.
  - Including a pattern or filename which matches a file, but the file
    cannot be opened.
  Note that because of the profile library architecture, it cannot
  generate extended errors.