Q:

Can anyone explain this one-to-one, one-to-many, many-to-one, many-to-many concept with respect to ORMs?

A lot of ORM sites and SQL tutorials mention these relationships as if they are obvious or to be taken for granted, but I don't fully understand why the distinctions need to be made.
Consider two tables A and B, both with id fields, and linkage(s) between these two tables.
My understanding is that:

One-to-one relationship: If you have a row in A, you have at most one corresponding row in B, and vice-versa. I think in this sort of scenario you could probably just combine the tables, possibly, but that's beyond the scope.
One-to-many relationship: If you have a row in A, you can have any number of corresponding rows in B. But if you have a row in B, there is at most only one corresponding row in A.
Many-to-one relationship: Already described in 2.
Many-to-many relationship: If you have a row in A, there can be any number of corresponding rows in B. If you have a row in B, there can be any number of corresponding rows in A.

So if this is the case then why, in an ORM, do we have to make the distinction between these cases? Why does it not suffice to say, "Here is object A. It holds either a reference or a list of references to object B." Why do I have to explicitly mention "This reference to object B? That's a one-to-one relationship." Or "this is a many-to-many relationship," etc.

A:

Because connection multiplicity is extremely important thing. And with important things it is better to be explicit than having magic figure things out.
What if for example A has list of references to B and B has list of references to A. Is this many-to-many relationship or two many-to-one relationships?
Just because A has reference to B and B has reference to A doesn't make it same connection. And if you cannot be sure, it is better not do do anything and leave everything to user of the library. ORM cannot get enough information from the object model itself. That is why additional metadata, either in form of XML or annotations is necessary to properly establish connections between entities and their multiplicity.
Something like this : 

Another way how to look at it is like this : with many-to-many relationship, if item of A references item B, the system also guarantees that B will reference same item A and vice versa. With two many-to-one relationships, this is not the case. Item of A can reference item of B, but same item B doesn't have to (but can) reference same item A back.
I have a question for you, how would classes for two cases in this diagram look like : 

Ok, last try trying to teach basic modelling. What relationships are in these classes : 
class A {
    List<B> RelationX;
    B RelationY;
}

class B {
    A RelationX;
    LIST<A> RelationY;
}

