Change type of InstanceBuilder.properties to Vec<(Ustr, Variant)>

[kennethloeffler]

This PR changes the type of InstanceBuilder.properties from UstrMap<Variant to Vec<(Ustr, Variant)> because I noticed that we were spending a significant amount of time just inserting into this HashMap during deserialization, and we get no benefit from this being a HashMap. The number of keys is usually small, and we only do a lookup here:

rbx-dom/rbx_binary/src/deserializer/state.rs

Lines 183 to 191 in e909f45

	fn add_property(instance: &mut Instance, canonical_property: &CanonicalProperty, value: Variant) {
	if let Some(PropertySerialization::Migrate(migration)) = canonical_property.migration {
	let new_property_name = &migration.new_property_name;
	let old_property_name = canonical_property.name;
	if !instance.builder.has_property(new_property_name) {
	log::trace!(
	"Attempting to migrate property {old_property_name} to {new_property_name}"
	);

which is a very cold path.

On my machine, this improves rbx_binary's "Deserialize 10,000 Parts" benchmark by ~11%, and will be even more significant on larger workloads.

[Dekkonot]

I was skeptical of this one because it turns has_property into an O(n) operation rather than (theoretically) O(1). However, I just did a benchmark and on my machine the worst-case scenario of having all 3691 properties took 47200 nanoseconds... So I think we're probably fine.

[kennethloeffler]

RIght, linear time property lookups on an InstanceBuilder would only be bad if it were an incredibly common operation - but it isn't, both for us and for our consumers. In this case, the cost of hash table bookkeeping outweighs the benefit of constant time lookup.

In contrast, attempting this kind of optimization on Instance.properties would actually make things worse, since the rbx_binary serializer has to look up lots of random properties over and over again, and consumers often want to do the same thing