Remove `const_get` from `StringIdentifierArgument` target

[okuramasafumi]

[Fix #425] const_get doesn't accept symbols that are something like :"Foo::Bar", and that's intended according to this issue. https://bugs.ruby-lang.org/issues/12319 Therefore, changing String to Symbol might not work as expected. As far as I know that's related to const_get only so we can remove it from the target of StringIdentifierArgument

---

Before submitting the PR make sure the following are checked:

• [x] The PR relates to only one subject with a clear title and description in grammatically correct, complete sentences.
• [x] Wrote good commit messages.
• [x] Commit message starts with [Fix #issue-number] (if the related issue exists).
• [x] Feature branch is up-to-date with master (if not - rebase it).
• [x] Squashed related commits together.
• [x] Added tests.
• [x] Ran bundle exec rake default. It executes all tests and runs RuboCop on its own code.
• [x] Added an entry (file) to the changelog folder named {change_type}_{change_description}.md if the new code introduces user-observable changes. See changelog entry format for details.

[Earlopain]

I don't think this is the right solution.

This should just skip interpolated strings for const_get. In addition it's easily analyzable if the string literal contains double-colons to prevent a false positive.

From testing, this also applies to:

• const_source_location
• const_defined?

These don't:

• public_const/private_const don't accept nested constants
• deprecate_constant as well
• Same for remove_const and set_const

[okuramasafumi]

@Earlopain You are right. At least this change must cover all affected methods. One concern is that the rule will be a little complex. Some might be confused about why it's not applied for some cases. We need to have a good documentation to explain.

[okuramasafumi]

@Earlopain What about this case:

const_get("#{process(name)}Resource")

Here, process method returns a string that MIGHT contain ::. Is it analyzable?

[Earlopain]

Perhaps in some trivial cases but generally no. I would just ignore those.

[koic]

I'll close this PR in favor of #430, which proposals a better resolution. Thank you.