stack/slapos: v↑ setuptools-dso 2.9 -> 2.10

With newer setuptools that is coming via https://lab.nexedi.com/nexedi/slapos/-/merge_requests/1550 (44.1.1 -> 67.8.0)
we will need a fix from setuptools-dso 2.10 to handle `python setup develop` well:

Previously with setutools-dso 2.9 and setuptools 67.8.0 built shared libraries were not
copied back into the working tree upon develop install which made anything
using pygolang to fail as e.g.

    $ ../bin/gpython
    Traceback (most recent call last):
      File ".../../bin/gpython", line 20, in <module>
        sys.exit(gpython.main())
      File ".../pygolang/gpython/__init__.py", line 456, in main
        pymain(argv, init)
      File ".../pygolang/gpython/__init__.py", line 223, in pymain
        init()
      File ".../pygolang/gpython/__init__.py", line 447, in init
        import golang
      File ".../pygolang/golang/__init__.py", line 41, in <module>
        from golang._gopath import gimport  # make gimport available from golang
      File ".../pygolang/golang/_gopath.py", line 65, in <module>
        from golang import sync
      File ".../pygolang/golang/sync.py", line 36, in <module>
        from golang._sync import \
    ImportError: liblibgolang.so.0.1: cannot open shared object file: No such file or directory

See epics-base/setuptools_dso#29 (comment)
and epics-base/setuptools_dso@2fdf75f2 for details.

P.S. NOTE that changing version of a setup-egg required egg currently does
_not_ force a rebuild. In other words pushing this change into testnodes won't
make pygolang t o be rebuilt at all. I think this is simply a bug in
slapos.buildout to fix.

/reported-by @xavier_thompson
/cc @jerome, @tomo, @Kazuhiko
/reviewed-on https://lab.nexedi.com/nexedi/slapos/-/merge_requests/1585

stack/slapos.cfg

@@ -303,7 +303,7 @@ scikit-learn = 0.20.4
 seaborn = 0.7.1
 Send2Trash = 1.5.0
 setproctitle = 1.1.10
-setuptools-dso = 2.9
+setuptools-dso = 2.10
 sgmllib3k = 1.0.0
 simplegeneric = 0.8.1
 singledispatch = 3.4.0.3