chore: bump go-steputils/v2 so an unrecognised Ruby install is not fatal

[lpusok]

Why

ruby.NewCommandFactory used to return an error whenever the Ruby install type could not be determined, which conflated two different situations:

1. no ruby in PATH at all — genuinely fatal, and
2. ruby present but installed somewhere we do not recognise — not a failure: the factory works, just without version-manager-specific handling.

This Step treats the error as fatal, so case 2 failed the build for no good reason:

rubyComamndFactory, err := ruby.NewCommandFactory(commandFactory, commandLocator)
if err != nil {
    return step.XcodeTestRunner{}, fmt.Errorf("failed to install xcpretty: %s", err)
}

bitrise-io/go-steputils#154 separated the two: only a missing ruby errors, an unrecognised install type warns. The new signature takes a logger, so the call site passes the one already in scope.

Found while fixing the other half of the same library bug in bitrise-steplib/steps-fastlane#116, which warned on the error and then panicked on the nil factory it kept. This Step never had that panic — it fails fast — so this is purely about not failing on case 2.

What

• go-steputils/v2 alpha.53 → alpha.54
• go-xcode/v2 alpha.80 → alpha.85
• the call site passes logger

The go-xcode/v2 bump is not optional: its autocodesign/devportalclient and xcpretty packages call ruby.NewCommandFactory as well, and every version before alpha.85 still uses the two-parameter form, so they no longer compile against the bumped library. alpha.85 (bitrise-io/go-xcode#345) fixes those call sites.

Most of the diff is vendor/ and go.sum: MVS pulls newer transitive versions along with go-xcode/v2 alpha.85. No first-party code changes beyond the one call site.

Verification

go build ./..., go vet ./... and go test ./... are green.