Make the YAML beam specification more uniform

[steven-murray]

It would be nicer for the beam definitions in the YAML to have a nicer YAML tag, or at least to be more consistent. That is, I think it shouldn't be possible to do e.g.

0: myfile.beamfits
1:
    filename: myfile.beams

Since in general other keywords should be supported, I think enforcing all beams to be of the form:

0:
   path: mybeam.fits
   other_param: ...

is better, and will mean more homogeneous code. As a further extension, one could imagine defining a YAML tag, so that it would be:

0: !UVBeam
    path: this.beam
    param: that
1: !AnalyticBeam
    type: gaussian
    diameter: 12.0

With these tags you can automatically read the YAML as python objects that are self-contained. The one reason you might NOT want to do this currently is that you actually don't want to read these things as full python objects, but rather in this weird "string mode" so it's lighter to pass around. I feel like there's a more pythonic way of doing this as well, but I'd have to think a bit harder. Possibly easier once the AnalyticBeam refactoring is in place on pyuvdata (see #443).

In fact, with the AnalyticBeam refactoring, we could reasonably easily do something like:

0: !UVBeam
    path: this.beam
    param: that
1: !GaussianBeam
    diameter: 12.0
2: !AiryBeam
    diameter: 15.0

[bhazelton]

We started the deprecation process for simple strings rather than dicts and for globally defined shape parameters in #444. More changes should be considered when we switch to using pyuvdata's analytic beams.

I'd also like to see if there's a better way to architect the beam list. I don't love the string/object mode switching.

[bhazelton]

This will be taken care of in #443