Initial support for calling golang, via reflection.

[skx]

This is a proof of concept for calling golang functions from yal, via the use of reflection. There's a bit of overhead in massaging the types into suitable forms - both for arguments, and results, but the core idea seems reasonable.

With this built and installed you can run:

> (path.Glob "/etc/p*")
((/etc/pam.conf /etc/pam.d /etc/papersize /etc/passwd /etc/passwd- /etc/passwd.org /etc/perl /etc/pipewire /etc/pki /etc/plymouth /etc/pm /etc/pnm2ppa.conf /etc/polkit-1 /etc/ppp /etc/printcap /etc/profile /etc/profile.d /etc/protocols /etc/pulse /etc/puppet /etc/purple /etc/python /etc/python3 /etc/python3.5 /etc/python3.7 /etc/python3.9) nil)

Needs more work in deciding what to add, and better conversion routines. (c.f. evalfilter).

TODO:

• [ ] - Decide what functions to add/migrate.
  • [x] - sin/cos/tan
  • [x] - random
  • [ ] - split
  • [ ] - directory:entries, glob
  • [x] - getenv/setenv
  • [x] - Replace toupper, etc, via aliases.
• [x] - Move (specials) from builtin-package to specials, and add keys from the Reflected map.
• [ ] - Better type conversion; we should be able to handle structs at least.
• [ ] - Can we handle opaque types to allow network calls? Worth trying.

But this updates #139.

[skx]

On reflection - pun intended - I'm not sold on this approach:

• Yes calling golang functions, via reflection, is neat.
• However handling all the argument/return codes is a little difficult.
• Implemented functions like this aren't discoverable
  • (help) can work with a hack, but (args), (body), etc do not.
  • Adding their names to (specials) is a bit of a sleazy hack too.
• Doing more things in yal proves it works, and is useful.
  • My old "toupper"/"lower" were ropy, but they worked.

I think there's a middle-ground here:

• Yes add support for reflection, but don't replace things like "(sin)", "cos", "tan", etc with it at the same time.
• Instead let users opt-in to call functions I've not implemented.

TLDR:

• Close this PR
• Replicate the "(help)" update for users.
• Allow something like:
  • (import 'strings "ToUpper" "ToLower")
  • That lets the user specify the function(s) to import.

However - major problem - you can't iterate over methods of a package. So I still have to hardcode options (such as "strings", "time", "os"). Meh. Maybe I should just abandon the whole idea?