[Proposal] Usage as module instead of CLI

I'm looking to integrate addLicense into an existing suite of internal FOSS compliance-related tooling, and part of that would be eased by decoupling the addLicense functions from the CLI-specific code that uses them. I'd like to propose the following changes (which I will happily create a PR for), but I wanted to check in with maintainers prior to doing so:

1. Turn `main()` into a function that consists solely of flag parsing and calling a new `Run()` function
2. Break out the rest of `main()` into a `Run()` function that takes in the parsed flag values and executes everything else (goroutines, etc)
3. Export `fileMatches`, `addLicense`, `licenseHeader`, `isGenerated`, and `hasLicense`

@willnorris et al, are there any thoughts or concerns about that approach? My over-arching goal is to increase composability.

Start at the CLI entry point in `main()` and trace the existing addLicense flow, including `fileMatches`, `addLicense`, `licenseHeader`, `isGenerated`, and `hasLicense`. Compare that flow with the proposed `Run()` boundary and confirm that flag parsing remains in `main()` while the operational work can be reused by another Go program.】【。

Written by the indexing model from the issue text.