review multi-organization setup

[migmartri]

Currently, the data model root is namespaced (soft multi-tenancy) by an organization entity.

Users are connected to different organizations through memberships, and the way we decide which one if the current is by a current database field.

To change the current organization you can use the CLI

$ chainloop organization ls
┌──────────────────────────────────────┬──────────────────────┬─────────┬─────────────────────┐
│ ID                                   │ ORG NAME             │ CURRENT │ JOINED AT           │
├──────────────────────────────────────┼──────────────────────┼─────────┼─────────────────────┤
│ 34970208-2f3c-4c6e-ad8a-88f2b2d2e04f │ integrations testing │ false   │ 10 Jul 23 09:23 UTC │
├──────────────────────────────────────┼──────────────────────┼─────────┼─────────────────────┤
│ 7d487b73-ba94-4d62-99a6-c54fa6ae0e2b │ chainloop core org   │ true    │ 03 Jan 23 13:25 UTC │
├──────────────────────────────────────┼──────────────────────┼─────────┼─────────────────────┤
...

$ chainloop organization set --id  7d487b73-ba94-4d62-99a6-c54fa6ae0e2b

The problem with this approach is that it can be very confusing for an user to see server-side persistence of these kind of configuration when it's more like a client/per-request basis. Imagine an user selecting an org in the UI and that affecting the CLI.

It will also make it more difficult for users and automation to work with multiple orgs.

Managing multiple "namespaces" (orgs in our cases) is a known pattern and we could solve it by making sure API calls always require an org ID, and the current org is stored in the client side configuration. We could make it work similarly to kubernetes, where you have a namespace set up. but it can be overridden through a global flag.

### Tasks
- [x] Expose organizations an user belongs to through the currentUser API endpoint
- [ ] Store the current org client side, we could store the first one if there is only one and prompt the user to select one if there is more than one
- [ ] The org set command could be used to set locally the current org
- [ ] Start sending the org ID in each API call
- [x] Update the controlplane middleware that loads the current ORG to start using this parameter instead
- [ ] Drop `current` column in the memberships DB