Add JSON data provider with sample number data

[sffc]

This PR includes:

• A DataProvider trait with related structs
• A JsonDataProvider implementation of the DataProvider trait
• Test cases demonstrating how it loads number symbols from a JSON data file

[sffc]

Okay, I did some cleanup. Let's review this now. This PR contains three main things:

• A DataProvider trait with related structs
• A JsonDataProvider implementation of the DataProvider trait
• Test cases demonstrating how it loads number symbols from a JSON data file

[filmil]

I'm personally OK with this commit to be merged. It may not be the last time we touch these files, so even if there are questions still unresolved there's time to address them.

[zbraniecki]

This looks generally good. All my comments are nits that we can iron out after landing.

My only high level concern is about component distribution that you're doing.

I'm not sure if separating components/utils from components/datap_json is the right way to go.

My vision would be to have a component called components/data_provider which has optional feature json.
When user includes data_provider as a dependency, they get access to the traits, and when they enable feature json they have access to JSONDataProvider.

@Manishearth - do you know of any prior art in Rust with deciding on such structures?

[sffc]

This looks generally good. All my comments are nits that we can iron out after landing.

My only high level concern is about component distribution that you're doing.

I'm not sure if separating components/utils from components/datap_json is the right way to go.

My vision would be to have a component called components/data_provider which has optional feature json.
When user includes data_provider as a dependency, they get access to the traits, and when they enable feature json they have access to JSONDataProvider.

@Manishearth - do you know of any prior art in Rust with deciding on such structures?

My thinking was that we may have several different data provider definitions, not only things like JSON or CBOR or Bincode, but also ones for caching, delegation, etc. Each type of data provider would go into its own crate. However, I can also see an argument for these to be modules within a single crate.

[zbraniecki]

However, I can also see an argument for these to be modules within a single crate.

I think that JSON is so omnipresent that it's ok to have it in data_provider itself. If we need CBOR and don't want to have it as a feature in data_provider we can then release data_provider_cbor as a separate crate, but I don't think it makes sense to separate between traits and JSON.

Either way, not blocking. Optional and up to you :)

[Manishearth]

@zbraniecki I think having a dataprovider crate that is just the traits and then individual crates for e.g. "json data provider" is the right way to go

[sffc]

OK, I filed follow-up issues for the open questions. I switched from String to LanguageIdentifier (let's discuss whether that's the right choice when we get closer to v1). If all looks good, please give one more rubber stamp so I can check it in.

[zbraniecki]

Agh, another round of nits. Sorry for that. I'm ok with you landing it as is of course, and still am reading and finding those little things :)

Feel free to land and address in a follow up.

[sffc]

Thanks; I implemented 2 of your comments, and opened #118 to follow up on the third.

[zbraniecki]

lgtm! thank you!