[Bitbucket Pipelines] “invalid response data” if manual steps not taken

### Are you experiencing an issue with...

shields.io

### 🐞 Description

When the default pipeline has manual steps, the shields.io badge breaks unless those manual steps have been attempted. This renders the badge unusable for repos that use manual steps for optional but rare tasks like releases. For example:

* 
* badge:
* API call:
* config:
* 
* badge:
* API call:
* config:

Looking at [the code](https://github.com/badges/shields/blob/afbc487faa79b2072cd3e74c11556f1fbdce9535/services/bitbucket/bitbucket-pipelines.service.js), my best guess is that the joi schema check fails, because PAUSED is not an acceptable .values[]­.state­.result.

### 🔗 Link to the badge

https://img.shields.io/bitbucket/pipelines/delan/nonymous/default

### 💡 Possible Solution

Updating the schema won’t be enough, because we later filter for builds with .values[]­.state of COMPLETED, which would exclude these builds because they are considered IN_PROGRESS.

Ideally we would treat the manual steps as optional, taking them into account iff they have been attempted, but otherwise generating the badge based on the non-manual steps. I’m not really sure how to do this though, and I found [the provider’s API docs](https://developer.atlassian.com/bitbucket/api/2/reference/resource/repositories/%7Bworkspace%7D/%7Brepo_slug%7D/pipelines/) unhelpful (but tbf I also have zero experience with it).

Start in services/bitbucket/bitbucket-pipelines.service.js and inspect the linked Bitbucket API response for pipelines with unattempted manual steps. Compare the two example repositories and determine how PAUSED and IN_PROGRESS states are handled. Done means the affected badge renders valid status data before manual steps are attempted while retaining correct behavior afterward.

Written by the indexing model from the issue text.