Remove excessive whitespace in map headers.

Use the "map" macro instead of using GROUP_* and MAP_* constants.
Also remove redundant "(bank then label)" comments.
Don't use Olivine maps to define the length of a map header.

The first and second map header labels have no semantic meaning with regard to length.
In fact, none of the labels are used at all.
Recomment type names.

This is mostly just whitespace reduction.
Use a macro for Odd Egg probabilities.
Add address labels used by Decompress.
Add labels for maps that reuse blockdata.
Cry "echo" is actually the upper byte of pitch (now a word).
Use macros for both types of map headers.

This should make map headers much easier to edit than before.

Rather than occasionally being able to reuse blockdata semantically,
create a label for each map and attach it to some blockdata include.
This improves readability and reduces overhead when adding new maps.

The macro argument length bug doesn't seem to crop up here...
It looks like it only happens when an argument is over 16 characters
long and references a symbol that exists before the macro is invoked.
Use macros for spawns and flypoints.

This firmly ties spawn constant definition to data allocation,
preventing usage earlier in main.asm or in other objects.

A potential solution is to abuse ifdefs and include it in
both main.asm and constants.asm.
Rename the internal PlayCry function to _PlayCryHeader.
Name cry functions in home.asm.
Move cry functions out of home.asm.
Use WOOPER in Oak speech.
Badge and move constants in Strength and Surf field effects.
Merge pull request #257 from yenatch/map-headers

Map header macros and misc comments
Condense cry headers to one line.

Keep the unused labels for readability (and maybe some symfile magic).
Merge pull request #258 from yenatch/spawns

Use macros for spawns and flypoints.
Merge remote-tracking branch 'kanzure/master' into cries
Merge pull request #259 from yenatch/cries

Shorten cry defs now that cry parameters are all words.
Remove the last incbin in map events.

Since it's unused there's no way of knowing for sure,
but movement data typically comes after scripts and
before text, and the commands make sense.