cc/gcc: remove 'sub-level' version form symbols

Now we use defconfig files to store the samples, we have to be a bit more
conservatives in the symbols names, so as to avoid gigantic version bumps
when updating sub-level versions from a package.

For example (using fictitious versions):
- in crosstool-NG 1.17.0, we choose:
- latest gcc is gcc-linaro-4.7-2012.10, which is the default for the
choice in the menuconfig
- gcc-linaro-4.6-2012.10 is selected
- so, sample has an explicit symbol for the selected gcc version, as it
is not the default
- we update to crosstool-NG 1.18.0:
- latest gcc version is gcc-linaro-4.7-2013.01
- gcc-linaro-46 has been updated to gcc-linaro-4.6-2013.01
- as the sample now has no *valid* symbol to set the gcc version, the
default is used, while we would have expected to still use the 4.6
release from linaro, not the 4.7

Get rid of sub-level (ie. the third digit sequence in versions) from the
symbols for linaro versions.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>

 # Kernel options

 menu "Operating System"

 # Config option used throughout the config and code to determine wether

 # we have a kernel or not (there might be different bare metal stuff)...

 config BARE_METAL

     bool

 config WINDOWS

     bool

 # Each target OS (aka kernel) that support shared libraries can select

 # this, so the user can decide whether or not to build a shared library

 # enabled toolchain

 config KERNEL_SUPPORTS_SHARED_LIBS

     bool

 config KERNEL

     string

 config KERNEL_VERSION

     string

 source "config.gen/kernel.in"

 comment "Common kernel options"

 config SHARED_LIBS

     bool

     prompt "Build shared libraries"

     depends on KERNEL_SUPPORTS_SHARED_LIBS

     default y

     help

       Say 'y' here, unless you don't want shared libraries.

       You might not want shared libraries if you're building for a target that

       don't support it (maybe some nommu targets, for example, or bare metal).

 source "config.gen/kernel.in.2"

 endmenu