Do Not Merge WIP towards a places component

[mhammond]

This is a simple WIP which creates a simple "places" component. It's very thin as code which currently lives in the application-services repo hasn't been copied here yet - see ./components/service/sync-places/README.md for more information.

This has been created primarily so a related PR in reference-browser makes sense and can be reproduced. We'll work with the a-c team to bash this into better shape soon.

[csadilek]

The general shape of this looks right to me!

[csadilek]

For sync-logins we have a separate sample app. We'd likely not add all sync features to the sample browser, I think. So, we'd have a sync specific sample app and the reference-browser (having all features.)

[grigoryk]

I think this looks fine. This is essentially a syncing counter-part to core-storage-local proposed in #1155. It'll be nice to have consistent naming. Maybe core-storage-sync?

As functionality for which we'd like to have multiple implementations is identified - such as the BrowserAutocompleteProvider you implement in mozilla-mobile/reference-browser#28 - that could be reified in a concept in a-c speak (an interface, with concrete browser-* components being defined in terms of that interface as opposed to concrete implementations). The HistoryTrackingDelegate interface from the engine concept is an example of this.

So this is likely to end up being split into two streams - a concept side which describes something like a "source of autocomplete data for the awesomebar", and concrete implementations here, in the local storage component, etc.

[pocmo]

Closing in favor of #1240