Add scheduling logic

[maruina]

Fix #20

Notes:

• Fix local development instructions with kubebuilder
• Fix indentation in README
• Change the function name to Owns, because then when we read pr.Owns(app.GetOwnersReference()) is clear that the Progressive Rollout owns the Application
• A scheduler that computes which applications we need to updated based on the stage parameters
• Scheduler tests
• New utils functions with their tests
• Updated the should reconcile integration test to work with the scheduler

[DiogoMCampos]

Added some comments and thoughts. In general it looks fine, there's a few clarifications (around App vs App Set, test cases, etc.) that might be needed and minor suggestions on comments and naming.

[sledigabel]

One more comments, on []Applications and stage types in functions, we seem to oscillate between pointer and value semantics.
I'd suggest we use pointer semantics everywhere for more clarity and avoid potential issues that will get very difficult to debug as the code base keeps expanding.

https://github.com/Skyscanner/argocd-progressive-rollout/pull/25/files#diff-b1a5cf22f2be07477047c7c268c9a2077f75c3fdadc285eb862dab8bc3aaad31R293
https://github.com/Skyscanner/argocd-progressive-rollout/pull/25/files#diff-c3753ff27e79b7da6571efc4fffc45e729b031a39337eec9b22a04425bbd69f0R12

I am not sure if there are standards around that specifically for operators, but generally speaking when dealing with structures that have a degree of identity to it (typically, an Application has an identity, it's deploying something to somewhere, and nothing else does that), Go tends to push you towards using pointer semantics.

[maruina]

I was using pointers where I was doing in-place update of a data structure, this is why we have func (r *ProgressiveRolloutReconciler) removeAnnotationFromApps(apps *[]argov1alpha1.Application, annotation string) error {...}

Regarding pointers vs value, I was using the majority of value because I thought it was easier to understand and I don't see any downside for our workload.

[sledigabel]

As discussed, would be good to have a wider conversation about it, as it'll cause some potentially heavy refactor.
but rather do it early than later.
Filed #33 for a follow up conversation

[sledigabel]

LGTM, adds a scheduling capability to the reconcile