Cross namespace relationships

The problem:

Right now namespaces are assumed to be used for versioning, though they could also be used for separating entire sets of resources in isolated namespaces. JR does not currently support resource relationships which cross namespaces. #893 attempts to solve this, but as I brought up in the comments there is the potential for the system to encounter a situation where the correct behavior is ambiguous or will be inconsistent depending on the order of serialization.

Proposal:

A simple set of resource resolution rules could be used to solve this issue without the need to specifically mark up relationships definitions on a resource.

Rules:

• All resource resolution will take place relative to the namespace of the request ("Request Namespace").
• Related resources will be assumed to be in the Request Namespace.
• Resource definitions will support a new method called global_resource which will register a resource type in a "Global Resource Map" to this resource class.
• Declaring two resources classes with the same type as global_resource will raise an exception or emit a warning, which should catch conflicts during development.
• If a resource class does not exist in the Request Namespace the Global Resource Map will be consulted for the resource class.
• Resources created from the Global Resource Map will still follow same resolution rules starting with the Request Namespace. In other words relationships in a global resource will first resolve based on the Request Namespace.

I believe these rules should allow unambiguous resolution of resources and prevent runtime issues where a resource is serialized with differing sets of rules (resource definitions), and meet the intent of #893.

Let's discuss this and other proposals here. I haven't tried to code this, but I think it's possible to modify the code to support these rules without a lot of refactoring. If you see potential road blocks in either this project or your projects please raise them here.

No se nombran archivos, pruebas ni puntos de entrada. Primero, revisa el comportamiento existente de los namespaces y de la resolución de relaciones, así como la discusión en torno a #893; después, aclara las reglas de resolución y define pruebas que demuestren un comportamiento inequívoco entre namespaces antes de la implementación.