packet: improve hardware reservations support using terraform dependencies

[rata]

This PR supersedes #119 and adds support for hardware reservations in Packet by adding auto-generated (i.e generated automatically by lokomotive) explicit terraform dependencies.

The need to use explicit dependencies on terraform (depends_on) is explained in the code itself, but you can have a look at these two links for more info (also linked in the code):
https://github.com/terraform-providers/terraform-provider-packet/issues/176
https://github.com/terraform-providers/terraform-provider-packet/pull/208

To guarantee that nodes with specific hw reservation UUID are created first, terraform dependencies are used and computed automatically in lokomotive. In contrast, PR #119 to achieve the same, did the following: terraform apply -target=<nodes_to_create_first> and then finished with terraform apply to create the rest of the resources.

The reasoning to change and rely on terraform for dependencies is simple: terraform already handles dependencies, handling them in different places is confusing and may hit several unexpected issues (as if running terraform apply -target=<nodes_to_create_first> we don't expect some resources to be created, but due to dependencies at the terraform layer they might be created if needed).

As explained in #119, I first started with the terraform -target approach because it was already used for DNS provider manual in packet, seemed simple and supporting all possible combinations of reservation_ids and reservation_ids_default seemed difficult otherwise. While working on #119, I decided that to support all combinations was not sane, and little by little, started to reduce the different combinations accepted. Basically, it was reduced and now reservation_ids and reservation_ids_default are mutually exclusive now. With that simplification in mind, going the terraform dependencies route seems simple. This PR just goes down that route, with this simplification.

There are some TODOs in the code, for things that I want to fully understand before merging, but other than that, this is pretty much functional.

Pending things:

• Add tests to new functions in this iteration and review other tests, just in case
• Address "TODO" currently in the code
• Create issue about plumbing to test terraform code (e.g. dependencies between devices, like we added here). Or should this be included here?

[invidian]

Just some nits and typos, otherwise LGTM!

[rata]

This is ready for review again, @invidian. PTAL :)

When it is ready to merge, I will create the issue mentioned in the PR description (the missing item in the TODO list)

[rata]

@invidian thanks for review and the patience while I tried different approaches! I think, however, time was well invested and the end result is quite better =)