brew: API installs do not handle `plist_name`

I feel like we should probably just add this to the service block and then it will get included with the API. The important thing is to make it backwards compatible in case someone outside of the core repo is using a similar pattern in their package definitions.

service do
  plist_name "name"
  service_name "name"
end

This would require some changes with how we check for commands before writing new service files since we shouldn’t actually do any of that without a run command defined in the service block. It also might require some changes to brew services for a similar reason. The point is that if we want to actually support this use case going forward we should give people a better API that is easier to use and also explicitly supported (remember the current use case is never mentioned in the docs).

We probably need to support something but that doesn’t mean it has to be in its current DSL form. If we’re embedding into the API then we cannot allow any dynamic elements (beyond OS/arch variations) so overriding a method makes less sense compared to a single line DSL. The current naming is perhaps confusing for some (service_name is Linux only).

Though we cope fine with the method model for caveats (albeit with some initial gotchas) so exact syntax probably doesn’t matter.

With that said, Homebrew/core should exclusively be public API so we should probably consider plist_name as public API at this point, particularly given its long-time use.

Something to keep in mind if planning to change the dbus or xinit formulae instead - changing plist name is a breaking change that would ideally be communicated in, e.g., the caveats, so best avoided unless that’s the direction we definitely want to take.

Maybe we could rename the plist during bottling?

If this works that’s fine, though if not then adding to the API JSON seems extremely trivial to do.