Organizational structure choices and Agile - Does it matter?

If the company wants different and more agile outcomes, they'll need at least one Done finished increment of immediate usable quality each Sprint. In Scrum, the Developers are accountable for ensuring this quality. Would it be possible for them to do so without QA testing?

I don't think it will matter that much, assuming that the broader organizational structures don't get in the way of motivated individuals on a self-organizing team being trusted by the stakeholders to deliver high quality software.

Specifically with quality assurance, the idea of independence comes up often. Having managerial independence of your quality assurance team members can help ensure that they aren't influenced, such as management pressure to shortchange quality and testing for faster delivery. However, independence often comes with a cost of additional management overhead and may not be necessary in your context. It's often more useful when building critical systems or in regulated environments.

The purpose of doing sprint is to give chance to stakeholders to inspect on the plan, progress, state of the product and adapt next sprint based on the feedback. If there will be some work to be done(like QA etc) after the inspection, then the sprint feedback does not reflected on the correct state/status of the product. So there are high chances for iterative way of working does not help your organisation to achieve the goal of the Agile transformation if the Scrum team is not cross-functional enough to deliver increments within a sprint.

I have worked in similar situations.  Since you mentioned that the company wants to move to Agile from waterfall, Scrum is not driving force in what you do.  Agile is a marketing term created by people that wanted to capitalize off of the Manifesto for agile software development.  However, being agile is main premise for why that manifesto was created and should be something that organizations in today's environment, that deal with fluid environments can use effectively.  

Being agile means that you are able to adapt quickly to changes.  Whether those changes come from environmental, economic or emotional is not a factor. It is just change that occurs quickly that requires adaption to work being done. How the organization of workers is done is often different from group to group.  The key is that the organization does not introduce gates, delays, or processes that decrease their ability to learn about or adapt to changes that happen. 

I have been with organizations that separated different disciplines.  Some of them were able to be more reactive, while others weren't.  I have also worked with organizations that created cross discipline teams.  Again, some were able to be more reactive, while others weren't.  What I have learned is that the organization structure isn't as important as the organization's attitudes towards creating smaller increments of valuable changes in shorter durations.  If the organization says they want to be agile but still require that there only be 4 releases a year and that every release goes through an extensive "full regression cycle", then they aren't interested in being agile. However they are interested in saying that they are Agile. 

My company is considering moving to Agile from waterfall development environment for embedded code and supporting mobile apps.

Why?  What is it that the company hopes to gain by doing this?  What need is driving the necessity to do so? Is there truly an understanding of what this transition means other than using some verbiage? Before the organizational structure is decided, the justification for putting the organization in turmoil and the willingness to change processes must be evaluated.  Without the willingness to change and a driving reason to do so, you won't see anything but new terms and confusion.