[Validation] Detect manifest variable shadowing

## Problem

We had a recent [issue](https://github.com/elastic/integrations/pull/4233) with a package where the same named variable was declared in both the package level manifest and the data stream level manifest. This was unintentional and I thought it could be an opportunity to improve package validation.

## Proposed change

Add a [semantic validation rule](https://github.com/elastic/package-spec/tree/834f8c35676a5d051898d4ac52bb770cf92167f1/code/go/internal/validator/semantic) that fails when it detects variable shadowing in manifests. The rule would need to consider variables declared at the root level, policy_template level, and data stream level. It needs to take into account that variables are scoped to an input type at the policy_template level and data stream level.

Or if variable shadowing / redeclaration is an intentional feature then the spec should document the expected behavior with respect to precedence. Developers need to know which value should be passed into the Agent handlebar template.

## Example of shadowing

In this hypothetical example `access_key_id` has been declared three times for the same data stream.

```yaml
# manifest.yml
vars:
- name: access_key_id
type: text
title: Access Key ID

policy_templates:
- name: billing
data_streams:
- billing
inputs:
- type: foo/metrics
vars:
- name: access_key_id
type: text
title: Access Key ID
```

```yaml
# data_stream/billing/manifest.yml
streams:
- input: foo/metrics
vars:
- name: access_key_id
type: text
title: Access Key ID
```