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.