Multi-properties should be indexed by default.

[RobertJacobsonCDC]

Currently the only use-cases of multi-properties is

• to index several properties jointly. (Also, to count combinations of different values, which is an index function.)
• to subscribe to property change events for a set of properties as if it were a single property.

Thus, it probably makes sense to make them indexed automatically.

Right now, you can define a multi-property:

define_multi_property!((Name, Age, Weight), Person);

And then, separately, you set the multi-property as indexed in a specific Context instance:

context.index_property::<Person, (Name, Age, Weight)>();

Why make the user do this?

It's not clear how to implement this. Right now we have no mechanism for a property to know if it's a multi-property, or more generally if it should be indexed by default. If we built this into the type somehow (e.g. fn Property<E>::default_indexed() -> bool), we could do a check in the PropertyValueStoreCore<E: Entity, P: Property<E>>. Alternatively, we could have a mechanism for creating different constructors for PropertyValueStoreCore<E: Entity, P: Property<E>>, one that indexes and another that doesn't. Entities Design Notes favors a method Property<E>::index_by_default().

[RobertJacobsonCDC]

Unblocked; implement against the v2.0.0 branch.

[RobertJacobsonCDC]

The ValueCountIndex feature of #678 calls into question whether (or how) this feature should be implemented. We now have three use cases for multi-properties:

1. to create a joint index on multiple properties
2. to create a joint ValueCountIndex on multiple properties
3. to simplify subscribing to value change events for multiple properties

Some options:

• Leave things as they are, forcing client code to call Context::index_property<Entity, Property>() or Context::index_property_value_counts<Entity, Property>() explicitly.
• Implement a "default index type" for properties, respected by PropertyValueStoreCore's constructor, which is some variant of

pub enum IndexType {
    Unindexed,    // Not indexed by default
    Full,                // Fully indexed by default
    ValueCounts // Only counts of values indexed by default
}

Then allow client code to create or remove an index for a property like so:

// Removes any existing index
context.set_property_index::<Entity, Property>(IndexType::Unindexed);
// Creates (lazily) a full index
context.set_property_index::<Entity, Property>(IndexType::Full);
// Creates a `ValueCountIndex`. (Would this remove a full index if one already exists?)
context.set_property_index::<Entity, Property>(IndexType::ValueCounts);

Incidentally, this opens the door to other user-selectable indexing strategies. We might imagine these options:

pub enum IndexType {
    // ... 
    BitVector, // Number of bits equal to entity population count is stored for each value. Intersections are fast.
    VectorStore, // EntityIds stored in a `Vec` instead of a `HashSet`. More efficient for many evenly distributed values.
    BTree, // Values are ordered, but slower for exact value lookup
}