Store inode in Entry, add accessor

[cehteh]

the d_ino field is mandatory in POSIX and clients (me) really need it when passing data
around. Keeping it in the Entry saves an extra stat()/metadata query.

[cehteh]

The 2nd commit may be not worth the costs of one additional file-descriptor. It started just
as thought experiment to implement Entry::metadata() which seems to be futile.

Nevertheless the functionality to 'remeber' the orginal directory is missing this can be done
on appplication side by wrapping the DirIter. Or I am considering to refine this to add a
'fat' DirIter to openat which includes the origin Dir and has some convinience
functions. Modestly lightweight would be to keep an origin: Option

in DirIter and only
store it on request (at construction time). The cost here is the file descriptor, not the memory.

Eventually when the necessary rust features stabilize (or there is some way to implement it) I
would still like Entry::metadata() (and few more: Entry::readlink(),..) possibly most
of the Dir api can be done on Entry as well...

[tailhook]

Yes i think storing a duplicate dir is too costly.

I think this could be done in application wrapper. And when using that, I would probably put Dir into Arc<Dir> instead and use that instead of duplicating file descriptor. Arc<Dir> is tremendously useful and I even considered to having it by default in this crate, but decided to be a bit more low-level and less opinionated. This change fits the same category.

[tailhook]

Should be libc::ino_t I think.

[cehteh]

I deliberately chosen the types from statx() (see #38) these are overall better suited than
the legacy types (which is a pain to deal with when differing in signedness). Arguably it
would been nice if statx() would define sx_ino_t or similar, but they are only aliases so
there isn't overly much value in doing so. In anticipation of statx() it would be a bit
awkward to return types as in struct stat which are sometimes inferior and kindof legacy.

[tailhook]

Note statx is a linux-specific call. This library also works on macos and different bsd variants.

Other than that, using libc types is convenient if you want to use other libc functions on that types. Because otherwise it will work on some platform but have compilation errors on others.

[cehteh]

I am aware that statx() is linux only. but the types it uses are well chosen to be a superset of what 'struct stat' provides. My plan was to provide 'accessor' functions that use these statx() types even when statx() isn't available.

I have some hopes that eventually other vendors pick this up and it becomes standardized. Anyway it could be changed to 'struct stat' compatibility. (also in #38)

[cehteh]

Pushed a new version which uses ino_t, removed the origin experiment.
The later will need more work and a complete different approach.

[cehteh]

Yes i think storing a duplicate dir is too costly.

I think this could be done in application wrapper. And when using that, I would probably put Dir into Arc<Dir> instead and use that instead of duplicating file descriptor. Arc<Dir> is tremendously useful and I even considered to having it by default in this crate, but decided to be a bit more low-level and less opinionated. This change fits the same category.

I am after low level (as long it doesn't compromise the 'rust' feel) as well. I had Arc in mind but turned that down.
I'll see and experiment :)