I believe the term you are looking for is input validation and sanitization. It is general enough to apply across multiple variations of the attack as you mentioned above and more. It would also include preventing attacks such as buffer overflows by preventing the attempted execution of code with an input that exceeds the designed limits.
EDIT - to add notes according to more specific scope
In the specific use cases presented, you are addressing the Web based attacks and are more concerned with telling the client what is data and what is code. Using this specific example, we'll dig into the HTTP protocol a bit to show what protections exists for clients and servers specific to this type of communication. The terms may vary across other protocols, but I can't possibly be expected to write about every protocol's communication in a short answer.
The best place to start with HTTP is HTML - Hyper Text Markup Language. HTML is the basis for data communication from a server to a web browser on a client. The client has a set of libraries which allow it to properly interpret the data received and take action according to the pre-programmed logic. By default, all data received is treated as data unless explicitly stated as code. In HTML that is accomplished with a script block and it's where all client side scripting takes place.
Now, this can be a concern in the event that a malicious actor finds a way to inject an ad or modify server code to serve additional blocks into the data stream that were not originally intended for the user to use. This is where injection attacks begin to take their place and need to be mitigated by both the client and the server.
On the server end, the server must ensure that all requests are handled properly including the receipt of data either from GET or POST transactions. Failure to do so can allow an attacker to impact services or embed code into a previously benign web page. Data handling/input sanitization is the key here.
So the answer probably is "there isn't a set term" but it's because transactions are assumed to be data unless the markup language indicates otherwise. This is why clients can shutoff java script and still browse web pages. They receive all the same data (barring AJAX calls of course), but they don't interpret the data as code since the engine has been removed.