LPS-48694 Service context ripped of

@brianchandotcom besides the email from @jorge.ferrer I'd like to note (cc @igorspasic-liferay):

- Remote services are not (or should not be) local services + security. Remote services are intended to be called from remote clients, so all adaptation for that aim should be done there (security check could be one of the adaptations, but others like change the signature is needed too). If we want to improve our remote API, we have to break this imposed constraint (consistency is not above aim, right?).

  - As a nice side effect, our local API would look like a real API: we could have domain-objects or model-objects in the signature. We could pass Company, User... full objects instead of companyId, userId plain ids... saving a lot of db calls and reducing the complex of the methods signature.

- We're mixing several concepts inside ServiceContext: first one is InvocationContext as Jorge said (the metadata to answer "where does this request come from?"). Others are Security/UserContext (all metadata for authenticated user), Page/SiteContext (where page/site, if any, is the source of the request?). We should split each concept in a separated entity/class/bean

Hope it's clear enough!