Create better Gitaly request count matcher

This week we've created and merged a new matcher, to guard against performance degradations regarding Gitaly request counts.

Example would be:

it 'limits the gitaly request count' do
   expect { subject }.to change { Gitlab::GitalyClient.get_request_count }.by(10)
end

@rymai suggested to put this in a dedicated Rspec matcher, which I agree with. This matcher should catch two cases:

1. Performance regressions
2. Performance improvements

The last case the Database matcher doesn't catch yet, so what could happen is that I improve performance one release but do not set the current improved performance as bar for everyone. The release after someone can add a feature or introduce a performance degradation but isn't notified.