Allow the Beats' shipper output to depend on the shipper client directly.

[cmacknz]

The Beats' shipper output currently clones the the shipper's generated protobuf client to avoid a dependency cycle between the shipper and beats: https://github.com/elastic/beats/tree/main/libbeat/outputs/shipper/api

We need to break this dependency cycle and ensure the API is only defined in a single place. Decide on an approach and eliminate the duplication of the shipper API between beats and the shipper. Initial options include but are not limited to:

1. Removing the shipper's dependency on beats by moving the code it needs to https://github.com/elastic/elastic-agent-libs. In the long term we should do this regardless, but it may be easier to wait until the shipper prototype is complete to avoid delaying implementation with package moves: Migrate beats code reused in the shipper to elastic-agent-libs #43
2. Move the shipper API definitions to separate repository specifically for the API definition and any reusable client code. The most obvious place is https://github.com/elastic/elastic-agent-client which is currently used for the agent control protocol. This would give developers a single repository to consume for working with the agent. The elastic-agent-client repository is currently owned by the agent control plane team.

[rdner]

We cannot really remove the dependency on beats right now because some code in the shipper still depends on beats: the queue

elastic-agent-shipper/queue/queue.go

Lines 11 to 12 in 18fb98d

	beatsqueue "github.com/elastic/beats/v7/libbeat/publisher/queue"
	memqueue "github.com/elastic/beats/v7/libbeat/publisher/queue/memqueue"

and monitoring tests

elastic-agent-shipper/monitoring/queuemon_test.go

Line 21 in 18fb98d

"github.com/elastic/beats/v7/libbeat/common"

(second could probably be migrated to the libs).

We should work on the queue to not depend on Beats, but we can create a new repo now and I think it's better for consumers, since it's going to be light-weight.