I know there are many release versioning schemes (e.g. Semantic), but I couldn't find any guidance about source code versioning. Do they have to be tracked by VCS (like Git) or they can be versioned independently? For example, I want to track misc versions of md5.c module independent of the projects in which the file is used.
First of all: Yes, you do want your code being version controlled from the very beginning. Never accept anything less than a full blown versioning system, preferably git, especially nothing like Dropbox or messing around with folders for your source code management regardless of the scale of your projects.
Branching schemes: Release versioning is mostly a result of a more wholesome code versioning approach. Usually you will want to implement a versioning scheme (=branching scheme) in your company and make people stick to it. From the growing code base releases will emerge and receive a version tag but still all the non-release versions are being version controlled at any point in time with the same system for everyone. This is the only way collaboration and maintenance can be made transparent and functional.
A popular branching scheme for more complex projects is the git flow scheme. Please find the documentation here. The basic idea is to have a continuous development branch that you merge new features (each being developed on a separate branch) into and from which releases emerge into a stable branch. Basically branches are used to sort code by its stability, starting from separate feature branches that can not even live on their own up to an ever trustworthy stable release branch.
There are other branching schemes, depending on the needs of your company like in the official git docu here or in the Bitbucket docu by Atlassian here. Have a look around and decide from the needs of your enterprise. Git flow is a good starting point but maybe you want something shallower.
Interdependent projects: A classic in software engineering. Say you have a package that you developed under version control. Now this package will be used by several others independently - will you copy it into each respective repository, essentially losing version control of it?
That is what submodules are made for. Git allows you to load repositories into repositories, basically nesting version control. Now you will develop your shared package like usual under the version scheme of your liking and simply import it into other projects (now it is called a submodule). When you implemented new features that you now want to see in the dependents you initiate an update and simply pull the new version from your original repository into the ones that use it (somewhat producer/consumer like), by so maintain development history upstream and always be transparent about which version of the dependency is living in each project.