Allow direct access through terraform_remote_state data blocks to other stack's TF states regardless of the space in which they are located

Right now spaces + access control features are also extended to the TF states, so that one source stack can read the TF state from another target stack, the source stack must be administrative, the target stack must have external state access enabled, and additionally, and this is the main issue/blocker for us, the target stack has to be located in the same or a child space, as indicated here (point 3):

https://support.spacelift.io/articles/9582913392-resolving-cannot-create-a-workspace-error-when-accessing-external-state

This is preventing us from being able to adopt the new spaces approach because of the following reasons:

• Spaces are mainly intended for access control and to group/constrict which resources can be used/attached to other resources (e.g. AWS integrations, policies, etc), and for all these cases, the inheritance works in the way that each child space inherits the permissions/resources/... from the parent spaces. For example, a group that has write access in a parent space is also inheriting write access in the child space, and in the same way, an AWS integration attached to a parent space can be attached to a stack that belongs to a child space. So far so good.

• However, for the case of reading remote states from other stacks, this is working just in the opposite way, since based on the link shared above, an stack can only access the remote state of another stack that is in the same space or in a child space, and we have verified that this is indeed working as indicated, which basically makes useless the inheritance concept in many use cases, since it is common that stacks in child spaces (with higher permissions granted to the teams) need te read remote states from parent stacks (managing base/centralized resources), which are usually more sensitive and therefore have more restricted access. This can not be achieved in this case, since the child stacks (with wider access) has to be located in parent spaces so that they can get remote state access to the parent (more sensitive) stacks.

• Administrative stacks (meaning stacks that are managing other Spacelift resources) need to be placed in the parent spaces so that they are able to manage resources in Spacelift belonging to lower spaces, and this is completely ok. The pain point is that reading remote states from other stacks, which has nothing to do with managing Spacelift resources, is using the same approach. Organization and relations in Spacelift context don’t have to be necessarily related with the existing relations across the resources managed by all the existing stacks in Spacelift spread across the spaces structure, since in many cases such as product companies, those resources managed across the stacks/spaces can perfectly belong to a single platform or stack.