I think user definable patterns would enable a better adoption of this plugin and reduce the maintenance. I am for it, since it will require the least communication between plugin developers (and reduce the risk that a API change will break the integration of other plugins.) Predefined pattern can be published on a subpage of the wiki plugin page. So every plugin developer and every enthusiastic user can publish patterns there for users to copy and paste them into the plugin configuration page.
Hardcoding of patterns could be done, but I would restrict it for the same reasons to a few bundled plugins and Jenkins (may be with an option to tweak it, in case something changes).
The API sounds fantastic but, as you mentioned, it needs the cooperation/awareness of other plugin developers. Therefore I see the priority of 1/ and 3/ would be "golden" version. You could also wait with the API until a few plugin developers showed interest/requested it, before implementing the api.
So in short:
I like the first solution, the third is second choice. The second I would leave out.