Prop enhacements

[dpbutter]

This is a rewriting of the internal storage of the Properties class to organize properties in a more hierarchical way. This allows get<> routines to run faster, which is important when there are hundreds of properties (for example in an intricate supergravity computation with many fields / tensors). Which combined with the comparator modifications (submitted in a separate pull request), I find ~5x speedup on complicated expressions.

The basic idea is to group properties by their type, so that e.g. Indices properties all sit together. These are organized in

typedef std::multimap<const property *, pattern *>	propmap_t; typedef std::map<std::type_index, propmap_t> typemap_t; typedef std::map<nset_t::iterator, typemap_t, nset_it_less>	namemap_t; typemap_t pats_dict; namemap_t props_dict; 

To eliminate some redundancy, I organized properties and patterns so that they always fundamentally sit in a propmap_t multimap, which itself sits inside a typemap_t.

The master typemap_t is the pats_dict, which is the analogue of the old pats.
To provide similar functionality as the old props, I introduced namemap_t, which maps names to typemaps. So a given prop/pat pair lives both in pats_dict and in props_dict.

(I swapped the props/pats order in props_dict relative to props because the above ends up being faster. Possibly this would be changed if patterns eventually become unique objects, i.e. a single pattern object can have multiple properties attached to it.)

To hide the internal storage from other classes, I introduce an iterator class and associated begin() and end() methods in Properties.

I also added functionality in Python to exhibit Property objects, with convenient erase() methods attached to them. The current display form of these could use some work.

Some comments:

1. I had to change the return values of Properties::master_insert and Kernel::inject_property, because of the possibility of a list_property being discarded in favor of an existing list_property. (The Python caller needs to know what the final property is.)
2. Since match_t only is used with list_property, I moved it from property to list_propery. Maybe this was wrong?

[dpbutter]

In Props.hh, there is some code

// Fuzzy bool type enum fbool {False, True, Unknown}; fbool castable(std::type_index to, std::type_index from); 

that could be removed as it doesn't do anything. I have been considering storing castability information to more quickly locate properties / avoid some dynamic casts.

[dpbutter]

I should also add: I left all the get calls elsewhere intact, but many of these can presumably now be specialized when the property class in question is a final class. Maybe one could simply add a flag to get<> that decides whether to get by castability or get by actual property. For the latter, there is a begin(std::type_index) that returns an iterator over a specific property class.

[kpeeters]

At the moment this breaks a number of tests (make test). I don't know if those are easy to fix, but maybe you can have a quick look before I spend more time on it?

[dpbutter]

Sure, I'll look at it this weekend. I'm not surprised it breaks some things.
(I'll check tests myself in the future for anything like this.)

[dpbutter]

Update: I haven't forgotten about the above, but got delayed a bit. I'll try to do that this week.

[dpbutter]

I believe I squashed the bugs. There were two:

1. I had designed the begin/end property iterators somewhat sloppily. They're fixed now.
2. In one of the Properties::get functions, my fingers typed if where they should have typed while.