Disagreements in token type are not handled correctly

[JakeWharton]

res/values/strings.xml:

<resources>
  <string name="library_text_argument">{name, date}</string>
</resources>

res/values-es/strings.xml:

<resources>
  <string name="library_text_argument">{name, number}</string>
</resources>

Currently this produces:

public object FormattedResources {
  public fun library_text_argument(name: Instant): FormattedResource {
    val arguments = ArrayMap<String, Any>(1)
    arguments.put("name", Date.from(name))
    return FormattedResource(
      id = R.string.library_text_argument,
      arguments = arguments
    )
  }

  public fun library_text_argument(name: Number): FormattedResource {
    val arguments = ArrayMap<String, Any>(1)
    arguments.put("name", name)
    return FormattedResource(
      id = R.string.library_text_argument,
      arguments = arguments
    )
  }
}

I suspect we simply want to enforce the types to match across all configurations and fail the build otherwise.

Are there any cases where you might want to have multiple types for a single token? Solutions to this depend on #29 a bit, since a workaround for that would be to name them differently (provided we allow this with an XML attribute somehow). Then at the callsite you would have to do library_text_argument(nameDate = someInstance, nameNumber = 12).

[JakeWharton]

Regarding this and #29, in ViewBinding the resource processing was split into three phases:

1. Parse resource XMLs in each configuration, warn or error on broken things within a single XML (malformed)
2. Merge resource XMLs by ID across configurations, warn or error on broken things across XMLs (semantic breakable such as disagreements)
3. Codegen from merged resource XMLs

We probably need a similar pipeline here. It may require two models, at least partially. Otherwise you might lose some info.

[JakeWharton]

This is actually a problem within a single configuration, too:
values/strings.xml:

<string name="hi">{count,date} {count,select}</string>