Prevent conflicting system resource parameters - #864

This should prevent the issues pointed out in #598 (except for the issue title).
If splitting up the TypeAccess tracking for local resources is the correct course of action too, then it potentially resolves #483 as well.

I think it can be useful to have multiple copies of the same Res<T> in a SystemParam. It enables encapsulation for sub-objects.

#[derive(SystemParam)]
struct Outer<'a> {
    inner: Inner<'a>,
    foo: Res<'a, Foo>,
}

impl<'a> Outer<'a> {
    pub fn use_inner(&self) { self.inner.use_foo() }
}

mod inner {
    #[derive(SystemParam)]
    pub struct Inner<'a> {
        foo: Res<'a, Foo>,
    }

    impl<'a> Inner<'a> {
        pub fn use_foo(&self) {}
    }
}

@bonsairobo do you have a fuller example? Inner is repeating the fields thar Outer already has access to.

I just mean that Inner might be some reusable SystemParam object, so you can build larger objects out of it. But sometimes both the inner and outer object need to access the same global resource. It shouldn't be a problem if it's Res, so disallowing this is limiting from a design perspective.

Makes sense ^^ it’s a small change to make the Res/ChangedRes checks look for only write accesses rather than reads/writes. I’ll push a change later today.

@memoryruins Thanks for hearing me out. I only spoke up because I've run into this issue before with specs, and I found it annoying that it wouldn't let me read the same thing twice from the same system.

Very good call! Thanks 😄

If splitting up the TypeAccess tracking for local resources is the correct course of action too, then it potentially resolves #483 as well

Yeah I think this is a good call. Right now its fine to just ignore local resource access in the scheduler because there are only two ways to access Local resources:

1. exclusive &mut World access
2. via the Local SystemParam, which is restricted to accessing the current system's local resource.

If we ever add the ability to access arbitrary Local resources in query systems, then we will need to take that in to account.