Unpatch: module features

[Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx>]

I've finished my first pass on module features; what I've got appears
to be working (tests are included and I've picked up some problems
with the existing module handling) and I'll commit it before doing
any more work.  I won't post it since it's large (the unidiff is about
8500 lines).

See the zmodload manual page for how it works, which is basically how we
discussed it.  The internals aren't quite how I vaguely suggested,
though they're similar.  I've updated Etc/zsh-development-guide.

Things still to do:

- I have not begun to look at autoloading, though existing autoloads
should work as they always have.
- The same goes for module dependencies.
- I have not updated zmodload completion, although it's clearly
useful to be able to complete features.
- I need to make another pass through the modules to see if there's
anything I've missed; I haven't tried out every single module, though
they should at least load.
- I think I will simplify return values from addparamdef and friends.
They have always had multiple return values of which we've only
ever used success or failure.  (I have also rewritten bits of modules
to use 0 for success like the rest of the shell.)  zmodload returns
status 2 if some features couldn't be set the way the user wanted:
examining the current state of the enables compared to the desired state
now gives a user-level way of sorting out the problem that we never
had before.  So I think we can dispense with any too hairy return
values internally.
- I am also not 100% percent sure the loading behaviour is right
with respect to error recovery.  For example, if a required module
can't be loaded, presumably the module being loaded should also fail.
Also, exactly what module function to call when one of them fails
during loading is a bit of a minefield.
- Some more comments in modules.c are probably warranted.
- The old addbuiltins() etc. calls have gone in favour of features.
I've made the setbuiltins() handles exported but I probably ought
to make the static within module.c to force modules to use struct
features.

Other comments:
- I have made zmodload -i behaviour the default (except for autoloads
where it did something a bit different).
- I have added zstat as an alternative to stat and changed shell
functions accordingly.  No function should now use stat.
- The shell never loads a module until it's required, so it's
not possible to interrogate features from an unloaded module.
There are ways round this in shell code (provided loading the module
with now features doesn't have side effects) so I'm not proposing
to worry about this.
- I haven't made hooks and wrappers into features since they're not
visible to the user, so it didn't seem to make sense.
- I tweaked some parameter handling, particularly with respect to
special variables.  There's a comment in typeset_single about one
issue.  createspecialhash() existed in several different forms inside
modules and has now been made an exported function; possibly it should
take a hash table size as a parameter since I now always create it with
size 0 which isn't always appropriate.
- Although I can't try this on AIX, where dynamic loading is
non-standard, I hope I've added all the things that are necessary.
- I've reordered module.c into a more rational form, so if you're
looking at a diff you'll get too many changes.

-- 
Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/