Allow custom denylist entries to be used alongside the built-in ones

[erawhctim]

We've adopted an internal copy of the DenyListedApiDetector to enforce our own internal API usage, which works great! but that means we don't get to take advantage of any updates/changes from the main lint check (without manually keeping our internal lint check up-to-date and routinely pulling in changes from upstream).

It'd be great if we could somehow supply an additional List<DenyListedEntry> to be used alongside the built-in entries; is that possible? Or even feasible, based on how these lint checks are published/distributed/configured locally?

Right now, we don't add slack-lints into our lint config due to the naming conflict that we would introduce between the two DenyListedApiDetectors. We could rename the internal one to avoid the name conflict, but we'd still be maintaining our own check implementation (so avoiding that and piggy-backing off of the official one would be convenient).

I'm happy to put up a PR to support this, but wanted to float the idea for consideration first. Let me know if you think we're approaching this problem the wrong way, or if you think we're better off to just build/maintain a custom check internally and call it a day.

[ZacSweers]

PR welcome, I'm not sure what kind of form this could take. Another alternative could be a service loader interface that we load and consumers could compile against. I think I'm partial to the latter to avoid file parsing