Every app other than "OS and manufacturer apps" means "third party apps".
Third party apps are those provided by a, hrm, third party. Though the following terms are non-existent, you can visualize this as follows: First party is the one providing the OS (AOSP/Google), second party the manufacturer (adding his own apps).
Basically, this can be read as: Everything that didn't come pre-installed. This is what the term "third party" normally is used for1.
You find some technical background in Android's permission system. If you browse the related pages on Android Developers or see my App permissions explained, for some permissions you will encounter the phrase "not for use by third party apps" (or similar). How does the system decide what makes a "third party app"? It looks at its signature and compares that to the OS and manufacturers' signatures. If the app's signature doesn't match any of the two, it's a "third party app".
In your question, the focus was to decide between "third party" and "developer" apps. Basically, in practice developer apps are rather a "sub-group" of "third party" apps. As the corresponding developer page states, to make debugging an app during development easier3, it can be signed "in debug mode":
You can sign an app in debug or release mode. You sign your app in debug mode during development and in release mode when you are ready to distribute your app. The Android SDK generates a certificate to sign apps in debug mode. To sign apps in release mode, you need to generate your own certificate.
You can run and debug an app signed in debug mode on the emulator and on devices connected to your development manchine through USB, but you cannot distribute an app signed in debug mode.
Thus "developer apps" can be told by using a known "debug certificate". As the quoted source states, this should not be used with "released apps" (e.g. a developer shouldn't publish any app signed this way)2.
1: though technically it might be not fully correct (example: in this context, what would an app be called which you manually installed, when it were signed with the same key as the ROM itself – i.e. was coming from the manufacturer?)
2: This is for security reasons. Apps might be able to access other apps' resources when using the same signature – a fact used e.g. by "addons" for specific apps written by the same developer (as the already named source e.g. puts it: Android allows apps signed by the same certificate to run in the same process, if the applications so requests, so that the system treats them as a single application. And: Android provides signature-based permissions enforcement, so that an app can expose functionality to another app that is signed with a specified certificate. By signing multiple apps with the same certificate and using signature-based permissions checks, your apps can share code and data in a secure manner). Using "your own" certificate protects "your" app from being accessed by "other developers' apps".
3: AFAIK you cannot install an "unsigned app", so signing it is a must. When "signing" an app, one usually needs to provide two passwords (one for the keystore holding your signatures, and one for the signature itself). Using "debug mode" signing, this can be avoided, as this uses an internal signature of the SDK with a password known by the development tools. This makes debugging a lot easier, as you don't have to type the two passwords over and over during the "compile › test › compile › test again › .." process.