Refactor to using pipeline for the API

[ErisDS]

This is an example as a talking point, it's not intended to be merged

refs #2758

• Shows how an API method could be refactored to use pipeline
• Each functional code block is a named task function
• Each function takes options, manipulates it, and returns options back
• Tasks like permissions can reject if they don't pass, causing the pipeline to fail
• Tasks like validating and converting options might be abstracted out into utils - the same for each endpoint
• Tasks like the data call can be extremely complex if needs be (like for some user endpoints)

[ErisDS]

I've updated this to cover all of posts, users and tags. I think the code is far more readable - and it's at least a lot clearer where the complexities are in the user API. CodeClimate hates me though - too much similar code!

The second commit refactors duplication out of the validation.

There are still like a gazillion refactors I could do here, but I'm thinking to add unit test coverage for api/utils.js, clean up the docs, squash and call this done. Any thoughts?

Update/P.S. - I plan to open up a beginner issue to roll out the pipeline to other endpoints.

[ErisDS]

Updated to include test coverage for api utils and tweaked the inline docs a bit (could be better). It should pass the build & I think it's good to go.

From here the plan is that I can sort out API option handling more easily, and also start to put in place a way to determine permissions for endpoints which are public (but have requirements like post status being published) so that we might be able to ship proper access to those endpoints using client auth.

[ErisDS]

This will pass once #5488 is merged and this is rebased on it