Add sublevel.getForces()

[Sascha-T]

Closes #7

Adds sublevel.getForces()
Format:

{
  "sable:force_name": {
    {
      "position": --[ vector ]--,
      "force": --[ vector ]--
    }
  }
}

or just straight up null if something goes horribly wrong.

The cody is a bit funky but it should be fine, works on my machine! :p
(I didn't increment any versions)

[TechTastic]

This could be a ConcurrentHashMap and thus locks and syncronization do not need to be explicitly handled by this class

[Sascha-T]

I can make it a ConcurrentHashMap but getLock is synchronized to prevent an evil style "race condition" where you can potentially create 2 seperate locks, but only one is stored in the Map, leaving a computer to wait for the (currently 2 ticks) lock timeout. (and from my understanding, a ConcurrentHashMap wouldn't change that?)

Or I just straight up don't understand where you want to go with this, please elaborate 🥺

[Sascha-T]

Actually I see the vision

[Sascha-T]

It took a minute but I think I found somewhat decent way to outsource concurrency back to Java, what do you think?

[Sascha-T]

I've been informed that getForces apparently behaves erratically (occasionally returns nil for no reason) so it appears there's still some more work to be done

Correction: not nil. But the other forces disappear, which may as well be a nil...