radio input: support for ngModel and value

[chalin]

Add support for ngModel and value radio input properties, matching the functionality available under AngularDart Material's <material-radio-group>.

[chalin]

Cf. angulardart/angular_components#61

[matanlurey]

We already support this:

<input type="radio" name="food" [(ngModel)]="foodChicken">

What else is needed exactly @chalin?

[chalin]

While there is ng2 support for ngModel over radio inputs, the current support isn't practical.

Let me illustrate this using the the example from lib/src/common/forms/directives/radio_control_value_accessor.dart:

@Component(
  template: '''
    <input type="radio" name="food" [(ngModel)]="foodChicken">
    <input type="radio" name="food" [(ngModel)]="foodFish">
  '''
)
class FoodCmp {
  RadioButtonState foodChicken = new RadioButtonState(true, "chicken");
  RadioButtonState foodFish = new RadioButtonState(false, "fish");
}

Notice that developers are forced to have a model variable of type RadioButtonState for each radio button and that only String values can be associated with radio buttons.

In ACX and ngTS, any type can be associated with radio button values, and only one ngModel is necessary. Here is an ngTS example of a list of radio buttons for selecting heroes:

  <label *ngFor="let h of heroes">
    <input type="radio" name="heroes" [(ngModel)]="currentHero" [value]="h">{{h.name}}
  </label>

The ngModel is bound to the currentHero; this is much easier to deal with than a collection of RadioButtonState fields.

Here is the same example in ACX, slightly adapted from webdev examples/ng/doc/template-syntax/lib/app_component.html:

<material-radio-group [(ngModel)]="currentHero">
  <material-radio *ngFor="let h of heroes" [value]="h">
    {{h.name}} ({{h.id}})
  </material-radio>
</material-radio-group>

cc @kwalrath @nshahan

[matanlurey]

Pushed to 5x.

[matanlurey]

I'm going to remove this from the 5x milestone since (a) I don't see many users hitting this and (b) we'd like to really get close to 5x as soon as possible. This could always be done in 5.1+.

[matanlurey]

We don't plan on working on this in the short/medium term.