Limit scope of assertThrows to minimum possible

[jamakal]

Describe the solution you'd like
I would love to see the number of lines pulled into the assertThrows be the minimum possible to make it clearer which method is actually being tested to cause the expected exception

Additional context
For example, a JUnit 4 test which asserts an exception is thrown such as the below:

import org.junit.Test;

import java.io.IOException;

public class TestTest {

    @Test(expected = IOException.class)
    public void test() throws IOException {
        // SETUP
        String s = "test";
        // ... Some more setup here ...

        // TEST
        testMethod(s);
    }

    public String testMethod(String s) throws IOException {
        throw new IOException();
    }
}

Will be converted to:

import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;

import java.io.IOException;

import static org.junit.jupiter.api.Assertions.assertThrows;

@DisplayName("Test Test")
public class TestTest {

    @Test
    @DisplayName("Test")
    public void test() throws IOException {
        // ... Some more setup here ...
        assertThrows(IOException.class, () -> {
            // SETUP
            String s = "test";
            // TEST
            testMethod(s);
        });
    }

    public String testMethod(String s) throws IOException {
        throw new IOException();
    }
}

One of the comments seems to jump to above the assert (potentially a bug?), but the main focus here is that the assertThrows encompasses the whole of the test method as opposed to the part which could throw the Exception.

It should be possible to limit the assertThrows to only the method which actually throws the Exception. Multiple methods throwing the same exception may be a little trickier. Unchecked exceptions probably couldn't be helped and would have to have the current behaviour.

[wlsc]

Hey @JamKage! Thank you for the suggestion -- I will take a look how I can reduce assertion to what's actually throwing such exception.
Regarding the comments not being properly transferred into the statement body -- yes, it must be a bug.

[wlsc]

@JamKage ok, the bug with comments in method body was fixed with this PR (#29) and will be available in version 1.4.1.
Regarding the scope -- need to see how I can reduce it further...