Profile include support, round 2

[ghudson@MIT.EDU]

Ken wrote:
> Under "interface design" it says "line[s] from the file are parsed
> as if they belonged to the original profile file".  [...] I'd label
> it good practice to always set the top-level section in the included
> file, and immediately after the include directive in the including
> file, to deal with these.

Although Ken didn't specifically ask for a change, I've decided that
it would be more conservative to ensure that include profile fragments
are syntactically independent of their parents.

My first thought was to reset the syntactic parsing state before and
after each include, but I thought of a simpler design: use a fresh
state for included files, sharing only the root section with the
parent.  So if you do something pathological like:

  krb5.conf:
    [sec1]
      var = {
        a = 1
    include /path/to/file
        c = 3
      }

  /path/to/file:
    [sec2]
       b = 2

then the resulting profile relations would be:

  sec1 -> var -> a = 1
  sec1 -> var -> c = 3
  sec2 -> b = 2 

I don't expect anyone to do anything that pathological.  But I could
see people doing something like:

  [plugins]
  includedir /etc/krb5/plugins
  # plugin fragments just assume they're already in the [plugins]

and I don't really want us to have to support that.

Does this design revision sound okay?  I will commit the change and
update the project proposal, but it's easily reverted if the dev
community prefers the preprocessor-like approach I began with.