Add problem labelling support

[randomir]

No description provided.

[arcondello]

LGTM

[JoelPasvolsky]

I'm only partway through but as it's approved I'll ask quickly before it's merged, @randomir can you say something about your considerations on explicitly having label in the sampling functions' parameters as you have versus pulling it out of **params? Thanks!

[randomir]

@JoelPasvolsky, I went with explicit because label is not a solver parameter (unlike **params). In the past, we added offset explicitly as well (which is an optional problem parameter). So, in each sample_* method we now actually have 3 categories of arguments: problem description, solver params and common/shared/sampling params (only label for now).

Originally, we thought to have label as a solver parameter, but to allow filtering by label, SSW decided to implement it level up, next to problem id, problem type, status, etc.

Alternatively, we could repurpose **params as **kwargs, and then split them lower down before the actual submit. Technically, that's trivial, but it's a conceptual change requiring docs update and additional explanation. So, this time I just went along with #2, even if that makes the code/docs more verbose.

[JoelPasvolsky]

Thanks, @randomir, that makes sense. I guess the reason this caught my attention is that I feel it's good to have the minimum number of arguments to sampling functions to make those simple conceptually for users, so every explicit argument should carry its weight, and it's not clear to me that most users will often use labels (they're very useful for examples such as those in dwave-examples and animated demos), but it's another argument they need to learn when they're getting started.

[randomir]

@JoelPasvolsky, I agree. FWIW, dimod samplers in dwave-system use kwargs, so we don't have to extract label as explicit argument there. Most users (especially new users) interface only with dwave-system samplers anyhow.