Fixes POST without accept for 3 endpoints

[jakesmolka]

Fixes default values and adds test for POST ehr, composition and
contribution.

Changes

• Fixes POST without accept for 3 endpoints
  • Fixes default values and adds test for POST ehr, composition and
    contribution.

More details on test changes:

POST ehr:

• existing MF-001 - Create new EHR (w/o Prefer header) already does check it. Renamed to MF-001 - Create new EHR (w/o Prefer and Accept header) to prevent accently refacotring away from that feature.

POST composition:

• created new commit composition without accept header keyword which basically is a copy of the normal one, but without Accept header.
• used in new Main flow has existing COMPOSITION and works without accept header test case

POST contribution:

• created new POST /ehr/ehr_id/contribution without accept header (... like above)
• used by newly created commit CONTRIBUTION without accept header (... like above)
• used in new Main flow: successfully commit CONTRIBUTION with single valid VERSION<COMPOSITION> withtout accept header test case

KW prepare new request session refactored:

• Requests can now be triggered w/ or w/o Accept/Content-Type headers
• JSON (default) - both (accept and content-type) set to application/json
• XML (both set to application/xml)
• no accept header (content-type=application/json)
• no content header
• no accept header xml (content-type=application/xml)
• no accept/content-type headers (other 'extra_headers' like IF-Match still possible)
• no headers

Related issue

fixes https://github.com/ehrbase/project_management/issues/175

Additional information and checks

• Pull request linked in changelog

[testautomation]

@jakesmolka

1. I found an issue which requires me to refactor an existing keyword or add and additional keyword. FYI: prepare request session KW sets Content and Accept headers to application/json even if called w/o format argument (JSON).

[testautomation]

@jakesmolka I had to use a little workaround where I set headers that should not be used to null. This should have the same effect as if that headers were not provided at all. I had to do this because one of the libraries we use (RESTInstance) sets some headers by default and does not provide an option to remove these defaults - they can only be overwritten. So something like Remove From Dictionary ${headers} Accept which you used for a RequestsLibrary request (i.e. here) does not work in case of RESTInsatance lib.