Create project context from current route and use for authorize check

[myieye]

Lots of our requests/endpoints will target a specific project, so we should have authorization built-in that checks if the current user has access to the project.

The current-project should be packaged in a tidy ProjectContext based on a consistent route param. Then we can pull the context out wherever we need it.

This is related to #2, where we're considering injecting this sort of project-context into our service or data-access layer, so we don't have to pass the project-code from the api all the way down to the DB.

[myieye]

(Migrated this from #2, because that's not where it's getting implemented.)

Here's a breakdown of the pros and cons I can think of regarding where to put the project-code:

	Header	Route
Standard	❌ No: the project-code is part of the resource identifier, so would normally be in the URL	✔️ Yes
Extra code	❌ We have to teach Swagger and our filter/auth middleware when a project-code header is required (and make sure these stay in sync). This will presumably be done with a RegEx in Swagger, which is maybe a bit tricker for humans to read than a route param.
Ease of use	✔️@hahn-kev: Easier for front end (I don't quite get this 🤔)
Declaration	✔️We define the rules for when a header is required in one place (rather than per controller/action), ❌ but these rules have to be kept in sync with new/renamed actions	❌ We have to follow a path-pram convention on each relevant controller/action

With that documented...I'm gonna go for the header approach and see where it takes me.

[longrunningprocess]

my $0.02

This seems like a project identifier to me upon learning more. With that in mind, I would prefer to see it in the path (or route). This seems more in line with REST conventions to me. Additionally, while putting something like this in the header is certainly an option, I don't think it's the best way to go here. If, for example, this was in some way related to authorization, the header would be a more appropriate place. I'd definitely be open to discussing this more in person if needed.

[myieye]

As discussed in our team meeting today: we'll put the project-code in the url not the header.