[coreboot] Shortened in types (u32) vs stdint types (uint32_t)

[mrnuke]

<rant>
stdint types are ugly as hell. That "_t" at the end is a pain in the ass to 
type, every day of the week. They're too freaking long for a variable type. A 
real pain. There is still widespread lack of adoption and FUD towards these 
types. I'm willing to bet that, had they been named properly, like uint32 (not 
a typo, there is no "_t"), the adoption would not be an issue.
</rant>

We normally use supershort in types in coreboot (u32). I am, of course, 
ignoring the legacy legacy types such as unsigned long, which have sadly 
persisted in coreboot source from the very early days. Personally, I'm a fan 
of u32 short types, and I really enjoy working with them. However, recent 
contributions to other projects have forced me to suck it up and deal with 
their stdint evil sisters.

To the real point: We have lots of recent contributions from google, which use 
stdint types. They're compatible with our old short types because, well, 
they're typedef'd from the same thing. The problem however, is that it creates 
more inconsistency within our tree. As a result, I propose we make stdint 
types mandatory, and deprecate shortname types. People don't want to learn a 
separate set of data types for every project  to which they contribute. stdint 
types solve this problem by being standardized. I am far from liking this 
change, but it just makes sense.

So, can we get votes of approval? I can add this info to the Coding Guidelines 
if there is enough support. Hopefully, we'll be able to migrate to stdint 
entirely, and drop shorties.

Alex