Infer resource kinds from support annotations

[saadfarooq]

I thought this might be a good feature to have while using the library. Android support annotations provide similar functionality to the kind annotation parameter so instead of duplicating the info, this change-set enables looking at the support annotation (which people should be using anyways) and setting kind to resource type if the support annotation used is one of the @res types.
The one additional special case is the @ColorInt annotation. Which this also checks for and sets kind to COLOR if it's used.
What are your thoughts?

[ZacSweers]

Aside from @ColorInt, how would this work for other kinds? Definitely get the appeal of @ColorInt, but I feel like the others wouldn't really make sense to reuse.

public class A {

    @StyledAttr(R.styleable.BarberView_stripeWidth)
    @DimenRes
    int stripeWidth;    // The IDE will now think this is a resId but code will use it as the evaluated dimen value?

}

[saadfarooq]

This is only avoiding duplicating info between a Kind.RES_ID annotation parameter and a @res support annotation.

// Case A
@StyledAttr(R.styleable.BarberView_stripeWidth)
@DimenRes // IDE uses this but barber doesn't
int stripeWidthResId; // resolves to.a.getInt
// Case B
@StyledAttr(value = R.styleable.BarberView_stripeWidth, kind = Kind.RES_ID)
@DimenRes 
int stripeWidthResId; // resolves to a.getResourceId

Without the changes case A is broken (even though it semantically makes sense) and you have to add the explicit Kind.RES_ID parameter as in case B to get it to work with Barber.
With the changes, Case A and Case B are equivalent. Barber infers that since the int is annotated with an @DimenRes annotation that the user intends it to be a resourceId and resolves to that case.

[ZacSweers]

Ahhhh I see what you mean now. In that case, yeah this looks good. I'm to think if there's any case where they might want a non-@_Res annotation for a resource ID, but none coming to me right now. One favor to ask though, would you mind rebasing and opening a PR against the z/resolvedattr branch? That's kind of acting as the develop branch right now

[saadfarooq]

Rebased

[ZacSweers]

This PR is still pointing to master, you'll have to close this and open a separate one pointing to the branch I mentioned to merge into that one.

[saadfarooq]

oh sorry... will do.