schema: Introduce ValueHint to LiteralType

[radeksimko]

Context

Currently, we operate with just cty.Types in LiteralType, which limits us during completion, hover or go-to-definition in certain contexts.

Use Cases

Here we could provide names of files in the current directory.

Here we have a couple of better options:

• treat {} as a map and provide completion for new items within it
• understand the templatefile() context, load all known variables from the file and offer those - this would likely have to be a special case which isn't handled by a ValueHint as expressing that in the schema would be tricky

Additionally there are situations where knowing the format of the value could help completion, e.g.

• aws_instance -> ami (ami-${1:}) - string pattern
• aws_vpc -> cidr_block (${1:127}.${2:0}.${3:0}.${4:1}) - IPv4 CIDR block

Finally (perhaps most commonly) there are many fields for which we could provide enum values, either statically declared in the schema, or dynamically sourced from an API:

• static examples:
  • aws_security_group_rule -> protocol
  • aws_security_group_rule -> type
• dynamic examples:
  • aws_instance -> instance_type
  • provider "aws" -> region

Static enums are also covered under #260
Dynamic enums are currently already handled by completion hooks hashicorp/terraform-ls#1017

Open Questions

• Could/should this also serve as TypeHint in the sense of matching e.g. references to AMI IDs against an attribute which accepts AMI IDs?
• Could/should this also serve as a way to express some simple static validation for each attribute? e.g. minimum length, regex, minimum/maximum, ...
  • See also decoder: Introduce ValidateFilePerSchema() #57

Proposal

TODO