Both BSD-3-clause and Apache-2.0 are permissive Open Source licenses. They permit combining code under these licenses with other code, especially also with each other. Both licenses would continue to apply for their respective parts, so it would not be quite correct to state that your project would be BSD-3-clause licensed.
In practice, the license conditions from the Apache-2.0 subsume all BSD-3-clause conditions so that to comply with both licenses, recipients (not you) would have to mostly comply with the Apache-2.0 license, and only add a copy of the BSD-3-clause notice to Apache's NOTICE file.
You don't have to choose the Apache-2.0 license for your contributions, but it would maybe simplify license compliance a bit for other people.
When you modify Apache-2.0 covered code, “You must cause any modified files to carry prominent notices stating that You changed the files”, but you don't have to describe the changes. This might be as simple as adding a copyright line in the file header. But since you want to license your modifications under a different license, your idea of prepending the new license notice is entirely appropriate. Here is how I would write such a license header:
foo.c is part of ExampleProject
Copyright 2022 How_To
Redistribution and use in source and binary forms, ... (rest of BSD-3-clause)
This code is based on OriginalProject
Copyright 2021 Original Authors
Licensed under the Apache License, ... (rest of Apache-2.0 header)
In such headers, it is common to put the most recent notice on top.
When you are not modifying Apache-2.0 covered code but are merely distributing unmodified copies, then things are simpler. Different scenarios:
A Git submodule is not a copy but merely a link. I don't think that adding an Apache-2.0 covered submodule would trigger any license obligations.
If you include a copy of the Apache-2.0 covered code into your project (for example, if you create a tar archive of your source code including the submodule), then you must comply with the Apache-2.0 license. Which here, just means including a copy of the Apache-2.0 license and the NOTICE file, if present. The upstream project likely already has this, but check to make sure. If you have a LICENSE or README file, I would add a note to mention that the code in a particular folder is governed by a different license, and where to find it.
If you distribute non-source versions of the software (such as pre-compiled executables) then you must comply with the licenses of all included components. This usually means including license notices (and the NOTICE files, if present) alongside the software in a ZIP archive or similar. Other software might have a help menu entry to show the notices, or have a
--version command line flag that explains where to find the full license. As a rule of thumb: wherever you give notice of your license + copyright, you should also mention the license + copyright of other components as well.
However, you do have forked/modified the project you're including as a submodule. Then you have to give notice of your changes in the forked/modified version. Instead of adding the BSD-3-clause notice header, you might instead add a copyright line with your name to the files that you touched. These modifications don't change anything when it comes to including the sub-project into your larger project.
So to summarize the answers to your questions.
Can you include parts from Apache-2.0 software in your project? Yes, but then your code will not be BSD-3-clause only.
How should you mark modified Apache-2.0 covered files? Your idea of adding your own license notice on top of the Apache-2.0 notice is on the right track.
How can you handle licensing for a submodule that you forked from another project? With respect to the contents of the submodule, modifying an Apache-2.0 covered project is equivalent to including Apache-2.0 covered parts into your code: you have to give notice that you made modifications, but are otherwise free to decide. In practice, keeping the Apache-2.0 license for those parts would be easiest. When bundling or compiling your software together with the submodule it's pretty much the same story, but it would be good to ensure that recipients know which parts are governed by which license.