Improve the NAS4Free version strings and filenames. Add VIMAGE support.

Patch does 4 things:

1. Build NAS4Free revision number into the kernel version string (e.g. 'FreeBSD 9.2-RELEASE-p3 #0 r262572+r972:')

2. Build FreeBSD kernel revision number into the output filename (e.g. 'NAS4Free-x86-embedded-9.2.0.1-262572-r972.img')

3. Build the embedded.img with a ".gz" sub-component in its name (e.g. 'NAS4Free-x86-embedded-9.2.0.1-262572-r972.gz.img')

4. Add "options VIMAGE" and "device epair" to kernel config.

---
Reasons:
---

1. Build NAS4Free revision number into the kernel version string (e.g. 'FreeBSD 9.2-RELEASE-p3 #0 r262572+r972:')

Reason:
So the Nas4free revision number "r958" can be shown in the kernel version string. This is great information, to output from the "uname" command or "sysctl kern.version". This info is also in the file "/etc/prd.version". It would also be great to print in the kernel string.

---
2. Build FreeBSD kernel revision number into the output filename (e.g. 'NAS4Free-x86-embedded-9.2.0.1-262572-r972.img')

Reason:
So the Sourceforge downloads page can show the "r262491" FreeBSD revision in the filename. So we (people like me) can identify the kernel version precisely. And build kernel modules for others. It is not likely that I myself am using that same nas4free version exactly than the target.

Why 2. again? Reason: It improves collaboration, for kernel modules.

Example A)
I am a user who is NOT on nas4free "r972" but wants to build for someone else a kernel module for "r972". I need to checkout the right FreeBSD kernel version e.g. "r262491" to reconstruct correctly the "/usr/src" tree. Knowning just only that they are on "r972" does not tell me all of the required information.

Example B)
To make some build farm. Such as to rebuild VirtualBox kernel module, whenever a new nas4free comes out and is published to sourceforge.net.

---
3. Build the embedded.img with a ".gz" sub-component in its name (e.g. 'NAS4Free-x86-embedded-9.2.0.1-262572-r972.gz.img')

Reason:
"embedded.gz.img" Filename. People often do 'dd' direct-copy the embedded.img file onto a USB flash drive. They need to know clearly it's a gzipped file. And must be uncompressed first before burning the disk image. It is very bad treatment to newcomers if they do everything correct. But yet the resulting USB does not work, just simply because you guys didn't give it a clear filename.

Note:
Someone on nas4free IRC channel said that the file is called ".img" because naming the file "img.gz" might cause some issue, perhaps when uploading the new firmware file. So my patch does ".gz.img" instead to be safe. However I couldn't see any specific problem in the nas4free code. And nobody I talked to could give any clear evidence any technical reason (in the code) for ".img" extension. 

From my investigations, I believe embedded file is most likely been named ".img" as just an arbitrary filename. If you come to the same conclusions as me, then a search-replace of the occurrences ".gz.img" --> ".img.gz". Will give the file it's correct name, as it should be.
---
4. Add "options VIMAGE" and "device epair" to kernel config.

Reason:
Improve networking support. VIMAGE cannot be loaded as separate kernel module. It must be built into the kernel itself. We use VIMAGE with 3rd party jails, to give them their own seperate virtual network interfaces from the host. It's absolutely no harm for those who don't use it.