Restler && Content Negotiation using Accept == TRUE

I initially only set out to validate the expression and heading to this pull request but since it was such an effort to work with the source code I decided to go another extra mile, wait make that two extra miles, so that I don't have to put myself through this again.

Things that MUST happen before I would consider working with this code base again, and some other friendly suggestions which you MAY consider.

 * Please pick a code convention and stick with it.

Which one is it now?

```php
<?PHP	if(expression){
			....
		}else{
			....
		}
````

or is it

```php
<?PHP	if (expression) {
			....
		}else {
			....
		}
````

or maybe

```php
<?PHP	if(expression) {
			....
		}
		else {
			....
		}
````

There are examples of these in restler.php alone. I really don't care what you decide but for the love of charity and all things pure please conform to something. It makes reading and working with the code an unpleasant ordeal. 

 * Please keep one line if statements on one line.

This kind of thing is a disaster waiting to happen and turns reading the code into a chore
```php
<?PHP

		if(preg_match('#^/\*\*(.*)\*/#s', $doc, $comment) === false)
		return  $this->params;
		$comment = trim($comment[1]);
		//Get all the lines and strip the * from the first character
		if(preg_match_all('#^\s*\*(.*)#m', $comment, $lines) === false)
		return  $this->params;
		$this->parseLines($lines[1]);
		return  $this->params;
```

If you have to use single line if statements keep them on a single line or at the very least add some indentation.

```php
<?PHP	if (expression) do_something();
```

or at least:

```php
<?PHP	if (expression) 
			do_something();
		some_thing_not_affected_by_expression();
```

The first example is preferable as you have to change it and cannot assume it already has open braces.

 * While doing the code sweep to fix syntax please do us a favour and clean the white space.

By removing excess trailing white space you make it easier for the rest of us who do to create usable patches that do not include changes related to whitespace differences which then makes it easier for you to evaluate, don't you think? There is a reason why most open source projects don't use tabs but rather 2 or even 4 spaces instead for indentation, we should ask ourselves why. Also diff complains if there is no extra new line at the end of the file which only adds to frustration.

 * Please make file placement intuitive .

I am not saying you should have [PSR-0](https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-0.md) conformance although it would make your framework more accessible   if we could use [composer](http://getcomposer.org/) to install it or include it as a requirement in our own packages. This would force you to use proper namespace and file location. We can get all the classes removed from a single file into their own files but ultimately it would be much less frustrating to look for and locate where a Format class is actually defined. Did I mention you get autoloading capabilities if you do it right?

Anyway there are more but these will go a long way in helping us help you so let me not waste more time complaining, what have we done for you?

After closer inspection I realized the problem was not what I thought it was in Luracast/Restler#46 but this is what the patch on offer now provides:

 * Content negotiation now works based on the request header Accept field.
 * Allow multiple mime type definition
   * text/xml and application/xml for XMLFormat
   * application/json and application/javascript for json
 * ensure that we only evaluate lower case mime types - you never know
 * Properly negotiate q levels for multiple mime types
   * RFC 2616 states that if q level is not provided level 1 should be assumed, we keep them in the order they were provided as well.
   * q levels are sorted to deduce the preference

ex. Chrome sends this Accept header field:
`text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8`
Which gets separated and sorted as follows 
```
1		text/html
0.999	application/xhtml+xml
0.9		application/xml
0.8		*/*
```
We will respond with the first matching type we find, which in this example is application/xml


A more complex and mixed around Accept header:
`text/*;q=0.3, text/html;q=0.7, text/html;level=1, text/html;level=2;q=0.4,*/*;q=0.5,application/json,text/richtext;q=0.9`

Is successfully ordered as: 
```
0.998	text/html;level=1
0.995	application/json
0.9		text/richtext
0.7		text/html
0.5		*/*
0.4		text/html;level=2
0.3		text/* 
```

By decreasing the factor differences for unspecified q levels we ensure that they remain high and only ensures preference due to location in the string. We can cater for 100 unspecified mime type entries.

 * RFC 2616 specifies that no Accept header = \*/\* which we can handle see nickl-/Restler@7329dd43342b052edf1f23d13bdd71b5789ee921
 * Also handle type/\*
   * application/\* = JSON
   * text/\* = XML
   * \*/\* = default format
 * We now properly communicate cache identification information by setting Vary: Accept as per RFC 2616
 * If we were still unable to find a suitable content type for you a **406 Not Acceptable** response is returned as per RFC 2616


Provided 3 separate commits with detailed commit messages explaining the changes further for your convenience. Enjoy! =)