REF: introduce constant refactoring

[Kobzol]

In this PR I'd like to tackle the Introduce constant refactoring. The current state is just a sketch, because I have a few questions:

• Should this work on arbitrary expressions (and types) or just literals?
• Where should the corresponding constant be generated? Maybe we should show the user a short dialog (similar to the Introduce parameter refactoring) to let him select? For example here:

//x
mod x {
    //x
    fn foo() {
        //x
        fn bar() {
            //x
            let x = 5;
        }   
    }
}

We could offer these 4 locations (inner function, outer function, inside module, outside module).

• Should literals with the same type and value in the given context (function/block) be extracted to use the newly created constant (same as with the Introduce Variable refactoring)?

Related issue: #4246

[vlad20012]

1. I think we can follow Java behavior. It work for expressions if they can be extracted to a constant. Otherwise it shows error message:
   
2. Java implementation by default uses class level, but if there are multiple classes it shows choose dialog
   
   But I like how scope selection works in kotlin's extract veriable:
   
   In addition to a chooser, it highlights the selection scope. Maybe it is overkill for constant extraction b/c scopes are usually large.
3. Java implementation offers a nice dialog with options =)
   

[Kobzol]

I tried two variants of the highlighting, the first one simply selects the scope:
https://gifyu.com/image/76Sh

And the second one inserts a placeholder comment (or something else) into the corresponding place:
https://gifyu.com/image/762e

• here obviously the places are wrong, that would be fixed
• the comments should disappear when the user selects a different place, however they seem to be immune to .delete()

What do you think? This selection would be shown after you select whether you want to replace occurences or not.

[Kobzol]

Added expression selection, auto import and interactive renaming (those features should be independent of highlighting).
https://gifyu.com/image/76pa

For some reason this works in Clion, but not in tests:

let x = /*caret*/5 + 5;

const i: i32 = 5 + 5; /// IDE
const X1: _ = 5 + 5; /// tests

In tests the BinaryExpr is not inferred to be of type i32 (it's TyUnknown instead).

[Kobzol]

Rebased over master.

[Kobzol]

I fixed the tests, they needed the stdlib ProjectDescriptor.

Here's how the refactoring currently looks like: https://gifyu.com/image/76pa. @vlad20012 let me know if there are any other changes that I should make.

[vlad20012]

👍 LGTM in general.

I'd want to see a more informative message if the expression is not extractable

[vlad20012]

Could you please squash these commits?

[vlad20012]

👍 Thanks!
bors r+

[bors]

Build succeeded:

• continuous-integration/appveyor/branch
• continuous-integration/travis-ci/push