gpython: Fix `gpython dir` and `gpython any.zip` to behave like std python

@vnmabus reports that gpython does not support running directories with main.py inside:

With normal python:

    >>> mkdir kk
    >>> echo "print('Hello')" > kk/__main__.py
    >>> python kk
    Hello

With gpython:

    >>> mkdir kk
    >>> echo "print('Hello')" > kk/__main__.py
    >>> python kk
    Traceback (most recent call last):
      File "./software_release/bin/python", line 313, in <module>
        pymain(sys.argv)
      File ".../parts/pygolang/gpython/__init__.py", line 284, in pymain
        run(mmain)
      File ".../parts/pygolang/gpython/__init__.py", line 188, in run 
        _execfile(filepath, mmain.__dict__)
      File ".../parts/pygolang/gpython/__init__.py", line 328, in _execfile
        with open(path, "rb") as f:
    IOError: [Errno 21] Is a directory: 'kk'

-> Fix that by teaching gpython to effectively use runpy.run_path instead of unconditionally assuming that first non-optional argument is path of a file. This adds support, similarly to how std python behaves, for running directories with main.py and zip archives with main.py inside.

We do not use runpy.run_path directly because that function stashes installed main module and uses fresh stub while running anything with removing the stub after the run. For our situation, however, that is incorrect, for example because with -i we need to inspect the state left after running the workload. Implement our own runpy.run_path custom analog ourselves to handle that correctly.

/cc @jerome
/fixes https://lab.nexedi.com/nexedi/pygolang/-/issues/2