Add a header option to combining_builder

The `header` option was removed from `PartBuilder` because individual builders no longer control the entire end file at `.g.dart` - it's now a concatenation of all `.something.g.part` files which might be produced by other builders as well. The ordering isn't controllable. Since we don't know which file will be first a "header" might not end up at the top of the resulting file.

We _could_ add a header option to `source_gen|combining_builder`. I was originally opposed to doing this because:

1. I only saw it being used for copyright headers and I didn't think that was a good justification.
2. It's really unfortunate that a user who only knows about the package they are directly depending on would need to learn about a new builder they aren't specifically asking for in order to configure a header, and the usage of `source_gen` and the combining builder becomes an implementation detail that the end user depends on.

I've now heard a new use case which is adding `//ignore_for_file:` comments for opt in lints that the builder authors aren't aware of.

I still think (2) is a bummer but this is a pretty good reason to want a header. Technically these comment don't need to be at the top of the file and we could put them back as "section headers" in the individual parts which might end up anywhere in the result file, but I'm not sure that's much better than having to learn about a new builder name to configure the header on.

cc @kevmoo who was right about this from the beginning.

Start by reading the combining_builder and the earlier PartBuilder header behavior described in the issue, including how .something.g.part files become the final .g.dart file. Define the configuration and ordering expectations for a header, then confirm that the proposed behavior supports the lint-comment use case without relying on uncontrolled part ordering.

Written by the indexing model from the issue text.