Plan Tracking for Vacate can result in a failure to the consumer when the plan is successful

## Overview

There are certain situations where we can have non-fatal errors in a plan; however, currently the way the tracking code works is that any and all responses along the way that might contain errors/warnings get bubbled back up as a fatal issue for that plan. In reality, there are situations where these things can happen, but the plan is still successful.

## Possible Implementation

It seems to me we need monitor the stream of events coming from the response tracking in order to evaluate whether the above is true.

The relevant code paths:

- [Tracking](https://github.com/elastic/cloud-sdk-go/blob/master/pkg/plan/planutil/track.go#L59-L76)
- [Streaming](https://github.com/elastic/cloud-sdk-go/blob/master/pkg/plan/stream.go#L83-L100)

How Vacates consume it (AFAICT it's the only consumer):

- [VacateCluster](https://github.com/elastic/cloud-sdk-go/blob/master/pkg/api/platformapi/allocatorapi/vacate.go#L303-L332)

POC (WIP): https://github.com/elastic/cloud-sdk-go/compare/master...Z3r0Sum:cloud-sdk-go:feat-overall-plan-success-tracking. Summary:

- This is an attempt to avoid sending what would be perceived as a 'fatal'
set of errors back to the consumer of the `TrackChange()` func.
- The scenario we are trying to account for:
- There are errors/warnings along the life of a plan as it relates
to a vacate
- The above do not cause the plan to halt
- The plan eventually succeeds
- The consumer receives these errors in a fatal manner when in
reality there is no cause for action
- Problems with current approach:
- Does not make the end user aware of any problems at all if the
plan succeeded. Not sure we care?
- TODO: thorough testing and confirm assumptions about the following:
- Do all fatal errors manifest themselves properly in the
plan-completed step, or prevent us from getting to it. If both
are true, this approach appears safe other than the problem
outlined above.

## Testing

- [x] Added unit tests
- [ ] Integration testing is needed/required

## Context

Vacates report a failure when in reality it was a non-issue and the plan succeeded along with the vacate of the instance.

## Your Environment

Internal SaaS.

Review pkg/plan/planutil/track.go and pkg/plan/stream.go to understand how tracking events and errors flow into pkg/api/platformapi/allocatorapi/vacate.go. Use the existing unit tests and the linked POC as context, then add coverage for plans with intermediate non-fatal errors and successful completion. Done means successful vacates are not reported as failures while genuinely fatal outcomes remain visible to the consumer.

Written by the indexing model from the issue text.