support withincode pointcut in the event definition

[yzhang90]

No description provided.

[owolabileg]

Minor: One more horizontal space

[owolabileg]

One more horizontal space

[owolabileg]

1. What's the use case (e.g., an example spec) that requires a withincode pointcut?
2. There are several other cases where more horizontal space should be added to new code, for consistency. I pointed out a couple.
3. What's the maximum number of imports from the same package before we import * from that package? I see several cases where the new changes imports * for relatively few imports. Perhaps keep the separate imports?
4. Please check that these are all the places that need to be changed, e.g., is withincode in a raw spec parsed properly?

[yzhang90]

1. What's the use case (e.g., an example spec) that requires a withincode pointcut?
   The withincode is used to pinpoint the exact instrumentation location. For example, I only want to instrument before db.put method when it is called inside dbStorage.put method.

    event putdbLock before ():
        call(* HaloDB.put(byte[], byte[]))
        && withincode(* HaloDBStorageEngine.put(byte[], byte[], int)) {
            System.out.println("Before acquire the putLock");
            dbPutLock.lock();
            System.out.println("After acquire the putLock");
    }

in this event we want to synchronize the db.put method and monitor state update code in the HaloDBStorageEngine.put(..) function.

4. Please check that these are all the places that need to be changed, e.g., is withincode in a raw spec parsed properly?
   I tried this change on a raw spec.

[yzhang90]

3. What's the maximum number of imports from the same package before we import * from that package? I see several cases where the new changes imports * for relatively few imports. Perhaps keep the separate imports?
   I change them to imports * because in the visitor class, we basically import all the class from the ast package. Do we need to list them one by one in the header?

[msaxena2]

@yzhang90 Looks good, apart from the formatting issue which has already been mentioned -

1. Seems like there is a file for unit testing the parser, although the number of tests seems to be extremely limited. Perhaps we can start improving the testing situation by adding a test for withincode?
2. Also extend the integration test using a simple spec that exercises withincode? This perhaps lies beyond the scope of this PR, since the integration testing may require a little more setup.