unrestricted readonly hashes

[rurban]

yves had in his yves/unrestricted_readonly_hashes branch rurban/perl@4628ab6 work to seperate readonly from restricted hashes, basically to allow fetch from unrestricted readonly hashes.

This feature is stable in the branch feature/gh57-hash-restricted, the question is only if to add it or not.

reopening, now that p5p is threatening perl5 with yet another outragious deprecation and change.
basically their spin is that locked hashes where only useful for fields, the old object system.
they only want to keep readonly hashes, but move locked hashes to a vtable interface.
http://www.nntp.perl.org/group/perl.perl5.porters/2017/01/msg242664.html
there are of course multiple problems with this approach:

1. locked (restricted) hashes still serve their purpose to disallow invalid keys, which is essentially error access to unknown object fields, usually caused by typos. this is still a very requested feature, our devs just requested it last week. readonly keys do not help, they only help with improved internal performance (perfect hashes: much faster, less memory, see XSConfig. Unicode tables not, they need something better).

2. a vtable interface makes it even slower and worse than it is now. cleaning up the messy implementation yes, already done in several cperl branches, but adding another indirection would make it even worse than better.

We will defer to use this branch for our new object system, which might rely on hashes or pseudohashes. And until we have no optimized readonly hashes. I see no way that p5p doing this will have any improvement, esp. changing the API that drastically. But it is a big threat as all of the things they are doing. Please raise your voice there.

in summary, this branch works fine, and seperates locked (restricted) from readonly-ness.
it is useful when implementing object accessors which need to be extended at run-time.
for closed objects and classes restricted can be kept combined with readonly-ness.