Pragmatic solution that's easy to implement
If you care more about a pragmatic solution that will likely work well enough in practice in most cases, and is easy to code, I would suggest storing each point in a quadtree. Then, for each triangle $T$, recursively search the quadtree to find all points within the triangle $T$. (This recursive search is pretty easy; at a node that represents a split of the space, check whether the triangle intersects the rectangular regions corresponding to the node's two children, and recurse on whichever node(s) it intersects.)
I don't know of any reason to think that the worst-case asymptotic running time will be better $O(nm)$ (e.g., it might perform poorly if you have many long, skinny, diagonal triangles), but it might work well in practice in many cases.
Alternatively, you could use a sweepline algorithm, similar to the Bentley-Ottman algorithm for detecting intersections among line segments. Unfortunately, it seems it might take quadratic time in the worst case.
Each triangle is defined by three line segments, so build the Bentley-Ottman data structures from these line segments. Also, you'll have an interval tree; for each triangle, it stores the interval of $y$-values that are obtained by intersecting that triangle with the current sweepline. Each point and each vertex of any triangle triggers an event when the sweepline hits that point or vertex. When you hit a point $p$, you can quickly count the number of triangles it is contained in: check the interval tree to see how many intervals in the tree contain it.
Each operation can be done in $O(\log(n+m))$ time. Unfortunately, there could be as many as $O(n+m^2)$ events (since there can be $O(m^2)$ intersections among the line segments), so in the worst case the total running time could be as bad as $O((n+m^2)\log(n+m))$. If you care only about typical running time, this might often do a lot better than that, as the number of intersections among the triangles might often be as little as $O(m)$, which would lead to a $O((n+m)\log(n+m))$ running time; but that's not guaranteed, and there exist inputs where it is much slower.