Add buffer ctors for properties APIs

[Manishearth]

Fixes the issue found in #7374

This was an oversight when we did new properties.

[Manishearth]

the Deserialize impl shouldn't be necessary.

[Manishearth]

Never mind; CPTs use T's serde impl in human readable mode.

[sffc]

Isn't there a macro that generates the whole impl for you?

[Manishearth]

We have generics here.

That's probably how we messed up in the first place, because we couldn't use the macro.

[robertbastian]

this was not an oversight, it was intentional. properties data markers are more stable than other crates, because each data struct is an enum that we can evolve by adding new variants. this means that we will never need fallback code in a buffer constructor, so we don't need buffer constructors.

[Manishearth]

I don't see the relationship between buffer providers and data struct format fallback. Data struct format fallback is something we can do with buffer providers (and don't need to do with baked), but that's a property of custom providers in general, and it's not their raison d'être.

There are at least two use cases for buffer providers in properties. Firstly, a low-memory application may choose to load properties on demand. I think this is a pretty marginal use case since the deserialization code has its own cost, but ... possible.

The other one is tailoring/private use: the OP in #7374 cared about that use case in particular.

We should have a stable ctor that allows one to load properties off of a buffer provider. Currently you need to use try_new_unstable.

If we are 100% sure that the marker will never change then we could design try_new_from_provider instead (which has try_new_unstable's bounds) but this would be a deviation from how we do data elsewhere and would need to be appropriately documented with examples for use with a buffer provider (since it's nontrivial to figure out you need to use AsDeserializing).

[robertbastian]

In any case this is a new API so let's discuss this in the TC.

[Manishearth]

Fair enough.

[sffc]

I favor adding with_buffer_provider here because of consistency and discoverability. It does not hurt to have the constructor, even if you subscribe to the line of reasoning presented by @robertbastian