Fix up incorrect PARTITIONED BY error messages

[abhishekrb19]

Prior to this patch, an incorrect PARTITIONED BY clause can expose options like NONE in the returned error message:

Invalid granularity[foo] specified after PARTITIONED BY clause. Expected SECOND, MINUTE, FIVE_MINUTE, TEN_MINUTE, FIFTEEN_MINUTE, THIRTY_MINUTE, HOUR, SIX_HOUR, EIGHT_HOUR, DAY, MONTH, QUARTER, YEAR, ALL, NONE, ALL TIME, FLOOR() or TIME_FLOOR()

Also, some of these granularities like SECOND and MINUTE are reserved SQL keywords that are not handled explicitly in Druid. In order for them to be properly used they should be quoted as literals. So single quote the granularity literals in the error message making it clear to a user about the correct usage.

Other related changes:

• A general overall clean up of DruidSqlParserUtils.java:
  • A mix of Precondition checks, ValidationException and DruidException were thrown making the calling code catch these different exceptions and unify them. So migrate all the exception handling usages in this class to DruidException and add additional context to messages as needed.
  • Remove unused method, modify a few method access modifiers, removed/added @VisibleForTesting, etc.
• Added a couple of tests for the literal granularity case noted above.
• Fix up some typos and inaccuracies in the javadocs for the partitioned by area of code.

Key changed/added classes in this PR

• DruidSqlParserUtils.java
• DruidSqlParserUtilsTest.java

---

This PR has:

• been self-reviewed.
• added Javadocs for most classes and all non-trivial methods. Linked related entities via Javadoc links.
• added unit tests or modified existing tests to cover new code paths, ensuring the threshold for code coverage is met.
• been tested in a test Druid cluster.

[abhishekrb19]

This conflicts with the note below, which is more accurate:

*Avoid partitioning by week, P1W, because weeks don't align neatly with months and years, making it difficult to partition by coarser granularities later.

[abhishekrb19]

Thought overriding a deprecated method for the sake of throwing an exception was not really needed.

[zachjsh]

should we test the expected granularity here too?