Tech Extensions: align API to UI needs

[nicolaferraro]

Track PR: https://github.com/syndesisio/syndesis-ux/pull/50

[nicolaferraro]

I've looked at the ux design and compared with current definition of the API (here and then), and from my point of view the following changes are needed:

• Add a GET /extensions/{id}/integrations endpoint to retrieve all integrations where a specific extension is currently used
• Add a parameter (also a query parameter) named updatedId that contains the physical id of the extension that is being updated (see update process of the ux) to the POST /extensions service that accepts the multipart data. I'd not model the update as a PUT, because it creates a new Draft extension with a new physical ID. The parameter can be used by the backend during validation e.g. to ensure that the new extension has the same logical id (extensionId field) as the extension being replaced.

@lburgazzoli, @gashcrumb do you think that something else is needed? Are list filters handled directly by the frontend currently or they require something from the backend?

[lburgazzoli]

Only one note for point 1, we should return only id/name pairs to the ui to avoid transfer of uber jsons ...