If a predicate has an `allowedConclusions` member, it will unmarshal
from a list `["a", "b", "c"]` into a set, so that the handler can easily
check if the incoming conclusion was allowed.

The `has_successful_status` predicate currently requires predicates to
be present and successful in order to pass. But workflows can be run
conditionally - for example only if certain paths change - and it is
currently not very convenient to write a policy which considers such
skipped workflows as passing. The only feasible workaround is to
duplicate the path filters in the policy, and this quickly gets unwieldy
and prone to getting out-of-sync in large repositories.

Here we add direct support for specifying such rules. This is done by
introducing a new alernative form that `has_successful_status`
predicates can take:

```yaml
has_successful_status:
  options:
    skipped_is_success: true
  statuses:
    - "status 1"
    - "status 2"
```

In this mode, we will consider the `skipped` result as acceptable. The
current form:

```yaml
has_successful_status:
  - "status 1"
  - "status 2"
```

remains supported. We have done this by implementing a custom
unmarshaling function to be able to handle both forms.

Closes: palantir#760

Implement `has_successful_status` in terms of `has_status` and deprecate
it.

This avoids us having two forms for one predidcate.

An example would be

```yaml
has_status:
  conclusions: ["success", "skipped"]
  statuses:
    - "status 1"
    - "status 2"
```

Mark it as deprecated instead of removing it.

This is more direct.

We want to test `HasSuccessfulStatus` now, so jiggle the testsuite a bit
to make that less repetitive by introducing a `StatusTestSuite` struct.

It's more code for not too much gain since we're only dealing with tiny
slices and not really looking through them that often.