Refactored the man.1 and added missing section

Uses convention from man-pages(7)[1].

[1]: http://man7.org/linux/man-pages/man7/man-pages.7.html
English fixes
Added a test for map a path that has been already mapped
Fixed map a path that has been already mapped
Fixed AppVeyor configuration to speed up the build process

* AppVeyor build only on 64 Bits OS

* Use the installed appveyor git
minor #64 Fixed AppVeyor configuration to speed up the build process (alquerci)

This PR was merged into the 1.1-dev branch.

Discussion
----------

| Q               | A
| --------------- | ---
| Bug fix?        | no
| New feature?    | no
| BC breaks?      | no
| Deprecations?   | no
| Tests pass?     | yes
| Related tickets | #38
| License         | GNU GPLv3

Commits
-------

8a3efe9 Fixed AppVeyor configuration to speed up the build process
minor #43 Refactored the man.1 and added missing section (alquerci)

This PR was merged into the 1.1-dev branch.

Discussion
----------

| Q             | A
| ------------- | ---
| Bug fix?      | no
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Related tickets |
| License       | GNU GPLv3

Uses convention from [man-pages(7)][1].

- [x] Fixed spelling by a native English speaker, @nylen.

[1]: http://man7.org/linux/man-pages/man7/man-pages.7.html

Commits
-------

fcceaa7 English fixes
226e6a9 Refactored the man.1 and added missing section
bug #63 Fixed map a path that has been already mapped (alquerci)

This PR was merged into the 1.1-dev branch.

Discussion
----------

| Q               | A
| --------------- | ---
| Bug fix?        | yes
| New feature?    | no
| BC breaks?      | no
| Deprecations?   | no
| Tests pass?     | yes
| Related tickets |
| License         | GNU GPLv3

It appears after `setup` that read the `/etc/setup/setup.rc` file with Windows path for the cache directory ([ref][0]).

[0]: https://ci.appveyor.com/project/alquerci/cyg-apt/build/1.0.190/job/4c85isv4adi9e3kl#L842

Commits
-------

72f75cf Fixed map a path that has been already mapped
fea26d7 Added a test for map a path that has been already mapped
Removed custum usage message on parse error

When the user sends wrong command line arguments the default behavior from
`argparse` python standard module is executed.
Removed the duplicated code for parsing the configuration file

At several places in the code logic is implemented to read the configuration.

The solution is to remove this duplication by pooling the business logic into
a single function (eg `parse_rc`).

Finally it will be better to read the configuration only once.
Improved the steps clarity into the main

Steps on the main are a little unclear.

So adding some comments to explain what's happening.

In the future it should be better to avoid writing a lot of code in it.
Fix platform detection for 32 or 64 bit Cygwin

If we're running in Cygwin's python, check sys.maxsize to determine
the Cygwin platform.

If we're running in Windows python, the python platform may not match
the Cygwin platform, so read the PE header of cygwin1.dll to determine
the Cygwin platform.

References:
http://en.wikibooks.org/wiki/X86_Disassembly/Windows_Executable_Files#File_Format
https://github.com/file/file/blob/b3f55f53/magic/Magdir/msdos#L79
Fixed file location for test
bug #8 Fixed the platform detection for 32-Bits or 64-Bits (alquerci, nylen)

This PR was merged into the 1.1-dev branch.

Discussion
----------

| Q               | A
| --------------- | ---
| Bug fix?        | yes
| New feature?    | no
| BC breaks?      | no
| Deprecations?   | no
| Tests pass?     | yes
| Related tickets | #26, #33
| License         | GNU GPLv3

- [x] Added a test for detecting the right architecture
- [x] Running test under Windows 64 bits platform

If running `cyg-apt` on Windows 64 bits and with a python 64 bits then It is not an obligation that the Cygwin platform is also on 64-bit. To avoid that indecision maybe we should add an `architecture` configuration field for the version 1.2.

However I was not successfully used `cyg-apt` outside Cygwin, I'll try try again. This is another issue but this issue need it. Moreover I cannot tests it on 64 bits architecture.

So for the moments we cannot say it works for 64 bits architecture without an efficient test suite.

From #26:
> This PR implements most of the functionality described in #8, except for an option to set the package architecture, which should not be needed.

Commits
-------

f709f82 Fixed file location for test
830368c Fix platform detection for 32 or 64 bit Cygwin
2529ef4 Improved the steps clarity into the main
7749d13 Removed the duplicated code for parsing the configuration file
cecbfef Removed custum usage message on parse error
Added Makefile GNU coding standards
Replaced from $(commands) to `commands`
Fixed the default value assignment
Fixed unexpected results when word starts with a dash

You should always keep in mind that any builtin or command may support options,
and therefore differ in behavior with arguments starting with a dash. For instance,
even the innocent echo "$word" can give unexpected results when word starts with
a dash.

It is often possible to avoid this problem using echo "x$word", taking the x into
account later in the pipe.
Fixed case don't need to quote the argument; no splitting is performed
Fixed `echo` portability

The simple echo is probably the most surprising source of portability troubles.
It is not possible to use echo portably unless both options and escape sequences
are omitted. Don't expect any option.

Do not use backslashes in the arguments, as there is no consensus on their handling.
For echo `'\n' | wc -l`, the `sh` of Solaris outputs 2, but Bash and Zsh
(in `sh` emulation mode) output 1. The problem is truly `echo`: all the shells
understand `'\n'` as the string composed of a backslash and an `n`. Within a command
substitution, `echo 'string\c'` will mess up the internal state of ksh88 on AIX 6.1
so that it will print the first character `s` only, followed by a newline, and then
entirely drop the output of the next echo in a command substitution.

Because of these problems, do not pass a string containing arbitrary characters to `echo`.
For example, `echo "$foo"` is safe if you know that foo's value cannot contain backslashes
and cannot start with `-`, but otherwise you should use a here-document like this:

    cat <<EOF
    $foo
    EOF