Implement function parameter interfaces for logical validators (`All`, `Any`, etc.)

### Terraform CLI and Framework Versions

N/A

### Use Cases or Problem Statement

Following #238, the remaining validators that don't support [parameter validation](https://developer.hashicorp.com/terraform/plugin/framework/validation#parameter-validation) (used in provider-defined functions) that are able to are:
- `Any` + `AnyWithAllWarnings` for all validator packages
- `All` for all validator packages
- `mapvalidators.KeysAre`
- `Value{TYPE}sAre` for all collection validator packages, like `listvalidator.ValueStringsAre`

### Proposal

These "logical" validators all accept in the attribute-based validator interface, like `validator.String`, which differ from the parameter-based validator interface, like `function.StringParameterValidator`. The differences are small however (notably error handling and data available), and are not relevant for the mentioned validators.

These validators all accept the attribute-based validator as input and we'd prefer to not introduce breaking changes by modifying/adding new inputs.

Two possible options I see (there could be others!):
1. In these validators, add type assertion logic to split/distinguish which validations should run on parameters vs. attributes and handle everything internally.
2. Introduce new `Any`/`All`/etc. variants that only work with parameter-based validation and accept that interface as input

Overall I think 1 is more preferable, however that does mean that anyone wanting to use the `All`/`Any`/etc. validators with function parameters would need to implement the attribute-based interface on any sub validators. This isn't necessarily a problem for the common validators in this Go module, but could be annoying for custom validators.

### Additional Information

_No response_

### Code of Conduct

- [X] I agree to follow this project's Code of Conduct