Add DCS-7060CX-32S support in boot0

[Staphylo]

Set the proper cmdline arguments to boot on a DCS-7060CX-32S in boot0.

@lguohan and @qiluo-msft in all the sonic codebase it seems like the hw_sku names for Arista platforms differs from the ones we actually give.
You use either arista_7050_qx32s or Arista-7050-QX32S in place of DCS-7050QX-32S. I agree that replacing DCS by Arista is better in this case but the dash/underscore being moved will yield some strange naming at some point.
Consider the SKU DCS-7050QX2-32S. With this one you'll end up with Arista-7050-QX232S since consistency matters in the naming.
I personally don't mind much since the transformation from our SKU naming to this one is easily done programatically but I wanted to bring that up before we add more platform and while we can still change it.
So I was wondering if I should go ahead and do the changes in sonic-buildimage (syncd, orchagent, boot0) and sonic-mgmt everywhere for the Arista-7050QX-32.
Otherwise, should I just do this only for the new platforms or should I just drop the idea and continue with the way it is currently done?

[lguohan]

there are two types of hardware skus in sonic. one is the real hardware sku, and another one is datacenter hw sku. The real hardware sku is used for load platform drivers, it should come from vendor. the dc hardware sku is mainly used for determine the wiring pattern since in datacenter scenario the wire pattern (port breakout mode) for a box is predefined. The one embedded in the minigraph is the dc hardware sku.

for you, I think you really care about the real hardware sku, we can follow your suggestion, for example Arista-7050QX2-32S ans use this to load specific platform driver.

As for the dc hardware sku, it is usually real hardware sku + breakout pattern string. It is mainly used in syncd process to supply the port configuration. Sometimes, the breakout pattern string is null to denote no breakout for all port.

In short, I think we probably should do followings:

1. seperate hwsku and dc_hwsku
2. adopt vendor name preferred name for the hwsku
3. standardize dc_hwsku or create a mapping between dc_hwsku to (hwsku, breakout mode).