Add reentrant capability to non-realtime mutatable

[why-trv]

Currently, one has to be mindful to limit the scope of ScopedAccess to avoid deadlocks if nested calls on the same thread are accessing the same RealtimeObject. However, maybe it's not the best idea to release and re-acquire the object before we're done with it, and it would be better to allow (optional) reentrant locking?

Example:

struct Coeffs {
    float a, b, c, d;
};

struct Foo {
    using RealtimeCoeffs 
        = RealtimeObject<Coeffs, farbot::RealtimeObjectOptions::nonRealtimeMutatable>;
    using Access = RealtimeCoeffs::ScopedAccess<ThreadType::nonRealtime>;

    void bar() {
        Access c(coeffs);
        // Doing something with coeffs
	
        qux(); // Deadlock
    }
	
    void baz() {
        {
            Access c(coeffs);
            // Doing someting with coeffs
        }
		
        qux(); // OK, but we're not really done, so maybe we shouldn't
               // be releasing and re-acquiring coeffs?
    }
	
    void qux () {
        Access c(coeffs);
        // Doing something with coeffs
    }

    RealtimeCoeffs coeffs;
};

I gave it a try in my fork (why-trv@9aba5f6) by storing the thread id and an access counter, does it make sense?