Add new resource: azuredevops_area_tree for managing area path hierarchies

[Levente Laszlo Papp (aklakina)]

All Submissions:

• Have you added an explanation of what your changes do and why you'd like us to include them?
• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing tests passed.
• My code follows the code style of this project.
• Have you checked to ensure there aren't other open PRs for the same update/change?

Description

This PR adds a new resource, azuredevops_area_tree, which manages an entire Area Path (classification node) hierarchy for a project as a single Terraform resource.

azuredevops_area (the existing resource) manages exactly one area path node per resource instance, which requires users to declare a separate resource instance per node and to reference sibling instances of the same resource type in order to build a hierarchy (e.g. a child node referencing its parent node's path output). This is needed because Terraform cannot dynamically resolve dependencies between sibling instances of the same resource - the graph is built statically from configuration, so a resource cannot safely depend on another instance of itself when the set/shape of instances is only known at apply time (e.g. derived from a variable or for_each over a dynamic structure). In practice this shows up as the well-known Terraform "Cycle" error, or forces awkward workarounds (hard-coded ordering, depends_on hacks, splitting the hierarchy across multiple terraform apply runs) whenever an area path hierarchy needs to be built or reshaped dynamically.

azuredevops_area_tree avoids this limitation entirely by taking the complete, desired area path hierarchy as a single, arbitrarily-deep nested object (via the paths argument, expressed with jsonencode) and owning the full lifecycle of every node in one resource instance:

• Creates every node in the tree, including implied/intermediate ancestor nodes that aren't explicitly listed.
• Prunes nodes that are removed from the desired state on update, since the resource has full visibility into both the previous and new state of the entire tree (unlike azuredevops_area, which only knows about its own single node).
• Tears down the whole tree on delete.
• Exposes area_ids and area_paths maps (keyed by slash-separated relative path) so other resources, such as azuredevops_team, can reference any node in the tree without needing sibling-resource lookups.

Because there is only ever one resource instance per project (no for_each over individual nodes), there is no possibility of the "Cycle" error, making this the recommended way to manage non-trivial area path hierarchies going forward. azuredevops_area remains available/unchanged for simpler, single-node use cases.

Does this introduce a breaking change?

• Yes
• No

This is a purely additive change: a new resource type, its documentation page, and a website navigation entry. No existing resources, data sources, or schemas are modified.

Test Result

Unit tests (resource_area_tree_test.go) covering the tree-diffing, create/update/delete, and import logic are included and pass. Acceptance tests (resource_area_tree_test.go under acceptancetests/) are also included, following the existing pattern used by other resources in this provider; they require a live Azure DevOps organization and credentials to execute (TF_ACC=1) and were exercised against a test organization during development.

Related Issue(s)

N/A - this is a new feature contribution, not tied to an existing tracked issue.

Other information

None.