Allow service resources to come from other code ids

Context from https://groups.google.com/a/puppet.com/forum/#!topic/orchestration-discuss/zbjks1faZAI

Today, when the master looks up service resources in PuppetDB, it does so using code id. It will specifically search for a matching service resource with the same code id, thus requiring that the producer node has run before the consumer and produced the "correct" service resource. We do this to avoid the consumer running against a soon-to-be-invalidated version of the service resource; in particular, we guard against the resource moving to a different node. If the corresponding service resource isn't found, we fail compilation. This provides a strict guarantee that agent runs absolutely cannot happen out of order, regardless of how they're triggered.

But many changes don't actually affect service resources. While we can't yet determine which changes those are, users often know. But our strict guarantee at the compiler level prevents us from allowing them to say "trust me, I know what I'm doing".

In order to enable features that put the power in the user's hands, we're proposing to prefer service resources with a matching code id, but not require them. This has two potential pitfalls: service resources could move between nodes and confuse us, and consumers could apply new code against an old service resource. For the former case, we can either find service resources by node, as we know from the environment catalog where they ought to exist, or only require a matching code id if there's ambiguity.

For the latter case, it seems that coordination in time is as important as order. If changes that need to span multiple nodes happen over the course of 30 minutes, even if they happen in the right order, things are bound to break. It's more critical that consumers run immediately after the producer than that producers have run before consumers. For that reason, the code id requirement seems insufficient. If it's important that changes happen together in time, the user should use cached catalogs and coordinate change exclusively with the orchestrator. In addition to that, using service resource availability checks will help avoid breaking changes in consumers.