Documentation on contributing

- Explain in detail the fork / pull request model
- Notes on git settings
- Notes on etiquette
- Notes on common workflows
Merge pull request #30 from raoulmillais/contributing

Contributing
Documentation on contributing

- Explain in detail the fork / pull request model
- Notes on git settings
- Notes on etiquette
- Notes on common workflows
Added translations endpoint
Ignored translation endpoint tests because the api is not public yet

- Confirmed tests passed with oauth key that can see internal apis
- Ignored the tests
- Fixed up some incorrect Xml serialisation attributes
Merge branch 'master' of git://github.com/7digital/SevenDigital.Api.Wrapper
Separate deserialization problem types in two

Scenario:
Consumer makes a request to the Release/Details endpoint.
Response is not really a Release/Details response.
It is still XML, and it has a <response> element, and an "ok" status,
but it is something else that cannot be deserialized to a
T==typeof(ReleaseDetails).

Previous results:
We were getting an extraneous "NonXmlResponseException", but the response
was clearly XML, so we have been some days trying to dig if the servers
where sending extraneous characters or BOMs that could not be well represented
when printing the ResponseBody in the stacktrace.

The real culprit of this bug we're getting is obviously not fixed by this
pull-request (we think it's a threading issue, more on that later), but at
least with this changeSet one could be not so confused!
Thanks
Exceptions: add serialization-friendly elements to recently created exceptions

(Following advice from Raoul.)
Exceptions: Remove SerializationException, .NET already provides it
Merge pull request #38 from knocte/reworkXmlDeserializationExceptions

Rework xml deserialization exceptions
Move attribute validation logic out of FluentApi and into separate class.
This also moves the instantiation of the RequestData object into AttributeValidation as its now this that provides the initial requestdata setup.
Keeping it simple at the moment, have started to separate the attribute code into private classes and the AttributeValidtion class is instatiated with the FluentApi ctor for the time being, but
makes the ctor much cleaner and could be added to in the future
Changed name to better reflect the behaviour of the class
Merge pull request #43 from gregsochanik/clean-attribute-validation

Move attribute validation logic out of FluentApi and into separate class...
Demo of how basket api schema should work using the same
model as with previous endpoints.
Each endpoint has it's own matching entity marked with the correct ApiEndpoitn attribute.

As their schema is the same, they all inherit from the base Basket which acts as the basket endpoint.

Future additions to this would be to remove some of the extension methods and replace them with a WithBasketId method as part of an ICanAccessBasket (or similarly named) interface

This potentially results in a breaking change, but would remove any dependancy on the WithEndpoint() method
Changed names of derived basket classes for easier readability
Merge pull request #47 from gregsochanik/basketschema

Demo of how basket api schema should work...