Question about time dimension and order members

**Problem**
Hi, I've noticed that if you have a time dimension with granularity set to `none` aka 'without grouping' it is still considered an order member, but IMHO it should not be that way. Why? Well, it doesn't make sense from a query perspective, and SQL generation seems to be confused by it.

I've tried to ask on Slack about this and had a short chat with @igorlukanin about it. [link](https://cube-js.slack.com/archives/C04NYBJP7RQ/p1694677856537849)

**Example**
As an example, I will provide generated SQL queries from the playground.

Here you can see that the order set on time dimension gets wrongly attached to the second column that is count.

Here you can see a similar problem where we have the order set on time dimension but also on the measure - the SQL query now contains two orders both applied on the second column.

**The question**
So I'm puzzled why a time dimension that has `none` granularity is considered an order member. There might be a deeper meaning that I might be missing so if anyone has some deeper knowledge about this I would love to hear the reasoning behind it.

**Proposed solution**
I've dug into the client core package and client vue package and found out it could be fixed by filtering out the time dimension that has granularity set to `none`... so I've created a [PR](https://github.com/cube-js/cube/pull/7165) that has this change at least for the vue package because I'm not very familiar with other frameworks you support with your client packages. The reason why each frontend package needs to be changed separately is because the client core package can't be used as a fix for this. The core package does contain a method called `getOrderMembersFromOrder` but it doesn't have any information about the granularity that is set to time dimensions.

Removing the time dimension (if granularity is set to `none`) from order members will fix the default ordering that is generated by the builder.

Thanks for reading 🙂